Building Engineering Culture in Indian Startups: Beyond the Ping-Pong Table

---

What Engineering Culture Actually Is

Before getting into the specifics of building it, I want to be precise about what I mean by engineering culture. Culture is not what you say your values are. It is not the posters on the wall, the Notion page titled "How We Work," or the annual offsite where you define your principles. Culture is what happens when a junior engineer finds a bug in production at 11 PM on a Friday. Do they fix it quietly and hope nobody notices, or do they flag it, document it, and loop in the team? Culture is what happens when a senior engineer's PR has a significant flaw. Does the reviewer point it out directly, or do they approve it to avoid confrontation?

Culture is the aggregate of thousands of small behavioral choices made under real conditions. You can shape those choices with the right structures, incentives, and modeling. You cannot shape them with a values workshop and a team lunch.

In my experience working with and observing engineering organizations across Indian startups at various stages, the specific culture challenges are predictable enough that you can plan for them. Let me walk through the most significant ones.

---

The Hierarchy Default

Indian organizations carry a strong hierarchical imprint. It comes from family structures, educational institutions, and a long tradition of organizational culture influenced by the colonial civil service and the early public sector behemoths. The implication in engineering teams is that the senior person's opinion tends to be treated as correct, and that disagreement with the boss is socially costly.

This creates a specific failure mode: technically inferior decisions get implemented because nobody in the room wanted to be the person who said "I think this approach has a problem." The hierarchy is respected at the cost of engineering quality.

I don't think the solution is to pretend hierarchy doesn't exist or to import a flat-organization mythology from Silicon Valley that is often just as fictional there. The solution is to create structures that make dissent safe and legible.

The most effective structure I've used is separating the technical decision from the social decision. When a design proposal is presented, I explicitly run a period of written comments before any discussion — typically 24 to 48 hours with the document shared in advance. Written comments are easier for junior engineers to make because there's no real-time social pressure. They can be reviewed without the author present. They're on record.

Then in the live discussion, I model the behavior I want explicitly. I ask the most junior person in the room for their take first. I respond to pushback on my own proposals with curiosity rather than defense. When a junior engineer's concern turns out to be correct and I was wrong, I say so clearly and publicly: "Rohan raised this concern in the doc comments and he was right. Let's do it his way."

This sounds obvious. It is remarkably rarely practiced.

---

Code Review Culture: From Rubber Stamps to Real Discourse

Code review is one of the highest-leverage technical practices in engineering, and it is one of the most poorly practiced in most Indian startup engineering teams I've seen. The failure mode takes two shapes.

The first: rubber stamp reviews. "LGTM" or a thumbs-up emoji without substantive feedback. Everyone wants to be collegial, nobody wants to cause delay, and the implicit norm is that raising issues in a review is an act of aggression rather than collaboration. This is especially common when reviewing code from senior engineers.

The second: brutal reviews that are technically correct but interpersonally catastrophic. Comments that read like accusations. Public callouts of "this is wrong" without explanation or alternatives. Reviews that crush junior engineers' willingness to submit code at all.

Neither extreme builds engineering culture. What does?

First, you need a written code review standard. Not a long document — a one-pager that specifies: what qualifies as a blocking comment vs. a suggestion vs. a question, the expectation that all blocking comments include an explanation and a suggested alternative, the expectation that authors respond to every comment (even to say "I considered this and decided not to change it because X"), and the expectation that reviews are done within one business day.

Second, you need the tech leads to model the review culture you want. If the most senior engineer in the room approves without comment or comments brutally, the whole team learns from that. When I'm reviewing code, I write the kind of comments I want to see: specific, educational, with alternatives, and kind in tone even when the feedback is hard. "This approach will cause issues under concurrent access — here's a simpler alternative that avoids the mutex problem" is always better than "This is wrong."

Third, you need to make review quality a team ritual. I run a monthly "best review of the month" recognition, where we share a PR comment thread that modeled the kind of technical discourse we want. This sounds small. Over six months, it materially shifts the norms.

---

Failure Culture and Blameless Postmortems

"Blameless postmortem" is a term that has spread widely in engineering culture, but in practice, it's hard to implement in environments where blame is the default response to failure. The Indian organizational default — again, not a cultural deficiency but an organizational pattern — is often to find the responsible party and hold them accountable. The instinct is understandable: if someone caused a problem, they should face consequences; otherwise, there's no incentive to be careful.

The problem with this instinct in complex engineering systems is that it's almost never the case that a single person caused a production incident. Systems fail because of the interaction of multiple decisions, configurations, and circumstances. If you focus the postmortem on finding the person who "did the bad thing," you miss the system-level learning that prevents the next incident.

Here's how I've made blameless postmortems work in blame-default environments:

I change the frame from "who caused this" to "what allowed this to happen." These are different questions. "Who caused this" has a person as the answer. "What allowed this to happen" has a system as the answer — a missing test, an unclear runbook, an architectural assumption that turned out to be wrong.

I make the postmortem template explicit about this framing. The incident timeline section asks "what happened" not "who did what." The contributing factors section asks "what system conditions allowed this failure mode to exist" not "who made these decisions."

I also run postmortems visibly, with leadership. If I hear a postmortem is going in a blaming direction, I intervene and redirect it in real time. The first two or three times you do this, it's slightly awkward. After that, the team learns the norm.

And critically: I follow up on the action items. The fastest way to kill the postmortem culture is to run them and then do nothing about the action items. Engineers stop taking the process seriously if nothing changes. The action items go into the engineering backlog with the same priority as product features.

---

Ownership Culture: From "Tell Me What to Do" to Initiative

This is the culture shift I find hardest to make and most impactful when it works. There is a "tell me what to do" orientation in many engineering teams — not because engineers lack intelligence or ambition, but because the default organizational dynamic has been to reward compliance and penalize initiative that goes wrong.

If you've spent your education in a system that rewards getting the right answer from the teacher and punishes wrong answers, and your career in organizations where questioning direction is culturally costly, you have been trained to wait for specification rather than generate it. This is not a character flaw. It's a learned behavior.

The shift I want to make is from "task executor" to "problem owner." A task executor receives a Jira ticket and implements it as specified. A problem owner understands the underlying goal, notices when the specification doesn't serve the goal, and proposes alternatives. These are different roles and they require different behaviors from the manager.

Concretely: I stop writing task-level requirements and start writing problem-level briefs. Instead of "build a rate limiter on the payment API," I write "payment API is being hit with a spike pattern that's degrading performance for legitimate users; what's the right solution and what are the trade-offs?" The engineer has to engage with the problem, not just implement a solution I've already determined.

I then review their proposal before they build anything, not to approve or reject it, but to engage with the thinking. What alternatives did they consider? What are the failure modes of their approach? This models the kind of thinking I want them to develop.

I also recognize and reward initiative when it works. Not with a token "good job," but with visibility — calling out the initiative explicitly in team channels, including it in performance feedback, and using it as an example for others.

This shift takes twelve to eighteen months to become the team default. The first few months, engineers often feel uncomfortable with the ambiguity. They keep asking for more specification. The key is to hold the frame: "I understand you want clarity. Let me share what I know about the underlying goal, and then let's think through the approach together rather than me handing you the solution."

---

The Moonlighting and Retention Reality

I'll address this directly because it's real: moonlighting and high attrition are significant dynamics in the Indian startup engineering market, and both are symptoms of a culture problem rather than causes.

Engineers moonlight when they're undercompensated, underutilized, or bored. If a skilled engineer can do their job in six hours and has nothing challenging to do for the rest of the day, the rational response is to take on consulting work. The solution is not a moonlighting policy — those are almost unenforceable and breed resentment. The solution is to give engineers enough challenging work that eight hours is genuinely occupied, and to pay market rate.

High attrition in Indian startups is driven by three things more than anything else: compensation not keeping pace with the market (Bangalore engineering salaries have moved significantly in the last five years), limited growth in scope and responsibility, and a lack of technical challenge. Culture programs don't fix compensation. They can fix scope and challenge, if done right.

The engineers who stay through difficult periods — and every startup has them — are those who feel they are growing, building something meaningful, and trusted with real responsibility. These are culture elements, and they're under the manager's control.

---

The Generational Shift

Gen Z engineers entering the Indian workforce have materially different expectations than those of older generations. This is not nostalgia or complaint — it's a structural change that leadership needs to understand.

Older engineers in the Indian tech market were often shaped by scarcity: fewer good engineering jobs, less negotiating leverage, more deference to organizational authority. Many internalized "working hard and being reliable" as the primary value proposition.

Gen Z engineers have grown up in a market with far more options. They've seen the startup boom. They have global content informing their expectations of work culture. They are more comfortable expressing disagreement, less tolerant of poor management, and more explicit about expecting work to have meaning beyond a salary.

This is not a bad thing. Engineers who can express disagreement clearly and who expect management to be accountable are valuable in the long run. But it requires leadership to shift from a command-and-control mode to a coaching mode faster than some leaders are comfortable with.

The specific things Gen Z engineers expect that older engineering cultures often don't provide: regular, honest feedback (both positive and constructive), transparency about company direction and decisions, flexibility in working arrangements, and work that they can see the impact of.

The culture you're building needs to account for both populations — the experienced engineers with older expectations and the newer engineers with different ones. The good news is that the culture changes required for Gen Z engineers are generally the same ones that make the organization better for everyone: honesty, transparency, meaningful work, and genuine feedback.

---

Building a Technical Brand

Culture is not just internal. The best engineering cultures attract good engineers from the outside because their reputation spreads. This is your technical employer brand, and it compounds over time.

The mechanisms: engineers from good cultures talk about it at meetups, in online communities, and to their networks. They share technical blog posts from their organization. They refer friends. Over time, this creates a self-reinforcing loop where good culture attracts good engineers who reinforce and extend the culture.

I've seen this work clearly in certain types of organizations. The ones that build strong technical brands share a pattern: they let their engineers speak publicly (conference talks, blog posts, open-source contributions), they do genuinely interesting technical work, and they treat their engineering teams with visible respect.

Building a technical blog, encouraging engineers to present at local meetups, and contributing non-confidential tooling to open source are all ways to build this brand. The cost is low. The long-term return in recruiting is significant.

The organizations that don't do this rely entirely on compensation and referrals to recruit. When the market gets competitive and salaries normalize, they lose access to the best candidates.

---

The Archetype That Gets It Right

There's a type of organization I've seen build genuinely strong engineering culture in India. It's usually a product company between 100 and 500 people — large enough to have real scale challenges but small enough that leadership can still model and shape norms directly. It's typically in a sector with genuine technical complexity: fintech infrastructure, SaaS with real enterprise customers, or consumer products with significant scale.

What characterizes these organizations:

Engineering leadership that codes (or coded until recently) and can engage deeply with technical decisions. Not just at the architecture level, but in code review and design discussions.

A documented engineering philosophy — not just values, but specific technical standards and rationale. The "why" behind conventions matters.

A promotion and leveling system that is transparent and merit-based, with clear behavioral definitions at each level rather than vague "senior engineer demonstrates leadership"-type criteria.

Investment in engineer growth: conference attendance, time for technical exploration, access to courses and resources, and explicit time allocated to internal knowledge sharing.

None of this is glamorous. None of it involves a ping-pong table. All of it is hard, sustained organizational work. But the result — an engineering team that is genuinely engaged, technically growing, and self-sustaining — is worth every hour you put into it.

---

Where to Start

If you're reading this as a leader trying to improve your engineering culture and feeling overwhelmed, here is the smallest possible starting point: pick one behavior you want to change and change the way you behave in that dimension first.

If you want more honest feedback, model honest feedback by sharing critical observations on your own decisions. If you want stronger code review, write stronger code reviews on your own PRs. If you want more ownership, stop providing complete specifications and start providing problem statements.

Culture follows leadership behavior. Change yours first, explicitly and visibly, and then build the structures that support the behavior you want to see throughout the team. The ping-pong table can wait.