📚 Technical Leadership Series - Part 1
This opens a new series on technical leadership, grounded in the roles I've actually held rather than leadership theory. Part 1 covers my time as a Lead Software Engineer at Nissan Digital India - inheriting a 12-person team, and the uncomfortable shift that eventually cut system downtime by 85%.
What you'll learn:
- 🔥 Why my first instinct as a new lead - being the best firefighter - made things worse, not better
- 🧭 The specific behaviors I changed to become a multiplier instead of the top individual contributor
- 📊 What the 85% downtime reduction actually came from
- ✅ A self-check for any engineer moving into a lead role
Lead Software Engineer
Nissan Digital India (TVM)
Led a team of 12 engineers responsible for systems supporting 9 global Sales Finance Business Units (SFBUs), including the Customer Master Data Management (CMDM) platform serving 15 regional operations.
Key Focus Areas
The Instinct I Had to Unlearn#
In September 2018, I stepped into a Lead Software Engineer role at Nissan Digital India, inheriting a team of 12 engineers whose systems supported nine global Sales Finance Business Units (SFBUs) spread across multiple regions.
I'd earned that role by being a strong individual contributor. So my first instinct, when something broke at 11 PM, was the same instinct that had gotten me promoted: jump in, find the bug, fix it, ship the patch, move on. For the first stretch of the role, that's exactly what I did. I was the fastest debugger on the team, and I made sure everyone knew they could escalate straight to me.
It felt like leadership. It was actually just individual contribution with a title attached.
The Uncomfortable Realization
The incidents kept coming at roughly the same rate. I was resolving them faster than anyone else on the team - and the team's overall reliability numbers barely moved. Being the best firefighter on a team of 12 doesn't scale past whatever hours I personally worked.
The Contrarian Part: Downtime Didn't Drop Because We Shipped More#
By the time I left that role in November 2020, system downtime across the team's systems was down 85%. Here's the part that surprised me at the time and still shapes how I think about leadership now: that improvement didn't come from a burst of extra shipping, more heroics, or more hours from me. It came from a shift in how I operated as a lead - deliberately stepping back from being the top individual contributor so the other 11 engineers could become genuinely capable owners instead of escalation points.
That's a harder sell than it sounds. Stepping back from the hardest bugs felt, for a while, like getting slower and less useful. It wasn't - it was the only way the team's reliability could exceed what one person's hours could produce.
The Shift, In Practice
The hero phase
I was the fastest responder and the default escalation point for every incident across all 9 SFBUs.
Key Achievements:
- ●Fixed the hardest production issues personally
- ●Everyone escalated to me first, by habit
- ●Incident rate stayed roughly flat
Deciding who owns what
Instead of being the answer to every 'who do I ask' question, I assigned clear system ownership across the team - mapped to the SFBUs they actually understood.
Key Achievements:
- ●Paired each engineer with specific systems and business units
- ●Made ownership visible so escalations went to the right person first
- ●Started running postmortems where the owning engineer presented, not me
Building the CMDM rebuild as a team effort
When customer-data inconsistencies across regions forced a real architectural rebuild, I sponsored and unblocked the Customer Master Data Management (CMDM) platform - but senior engineers on the team led design and delivery.
Key Achievements:
- ●Senior engineers owned the event-driven architecture decisions
- ●I focused on removing organizational blockers across business units
- ●Recognized twice with Nissan's Best Trainer Award (June 2019, Feb 2020) for mentorship during the Freshers' Training program
Reliability became the team's habit, not my hours
By the back half of the role, engineers were resolving and preventing incidents in systems I hadn't personally touched in months.
Key Achievements:
- ●System downtime down 85% versus the start of the role
- ●On-call load spread evenly instead of defaulting to the lead
- ●Postmortem culture caught recurring issues before they repeated
What Actually Changed#
1. I stopped being the answer and started being the unblocker#
The single highest-leverage change was refusing to be the default escalation path. When an engineer brought me a production issue, my job shifted from "solve it" to "help you solve it, then make sure you're the one who owns this system going forward." It was slower in the moment and faster over every month that followed.
2. Ownership had to be explicit, not assumed#
Across 9 SFBUs and a growing set of interconnected systems, "someone probably owns this" is exactly how things fall through the cracks. I learned this the hard way while building the CMDM platform - when multiple regions could touch the same customer record with no single owner of the truth, conflicts didn't average out, they compounded. The fix at the system level (a golden-record data model) and the fix at the team level were the same principle: name an owner before the ambiguity turns into an incident.
3. Postmortems became a mentorship tool, not a blame exercise#
I moved postmortems from "the lead explains what went wrong" to "the owning engineer walks the team through what happened and what they're changing." That single format change did more for the team's collective incident-response skill than any amount of me personally fixing things faster.
4. Mentorship was the multiplier, and it was measurable#
Nissan recognized this shift with its Best Trainer Award, twice - June 2019 and February 2020 - for my role in the Freshers' Training program. That recognition wasn't for technical output. It was for time spent building other engineers' capability, which is exactly the kind of work that doesn't show up in a sprint report but shows up eighteen months later in a downtime graph.
What the Shift Actually Produced
System Downtime
Reduction across the team's systems, Sept 2018 to Nov 2020
Team Size Led
Engineers across multiple specializations
Business Units Supported
Global Sales Finance Business Units (SFBUs)
Regional Coverage (CMDM)
Regional operations unified on one master data platform
Data Inconsistencies (CMDM)
Reduction in customer-data conflicts across regions
Recognition
Nissan Best Trainer Award, June 2019 and Feb 2020
Individual Contributor Lead vs. Multiplier Lead#
The Two Ways to Lead a Team You Just Inherited
The lead is the fastest, most trusted problem-solver on the team
✅ Pros:
- •Fast in the moment - the lead genuinely can fix things quickly
- •No ramp-up time explaining context to someone else
- •Feels like clear, visible leadership
❌ Cons:
- •Reliability caps out at one person's working hours
- •Engineers don't build the judgment to own systems themselves
- •Every vacation or sick day becomes a risk
The lead's job is building 11 other people's capability to own outcomes
✅ Pros:
- •Reliability scales with team capability, not lead availability
- •Postmortems and ownership create compounding improvement
- •Mentorship pays off in incidents that never happen
❌ Cons:
- •Slower in the first few months - real investment before real payoff
- •Requires giving up the satisfaction of being the hero
- •Harder to measure day-to-day than 'bugs I personally fixed'
The Self-Check I Use Now#
Whenever I step into a new lead role, I ask myself these questions early - because it's easy to default back to individual-contributor habits without noticing:
Am I Leading, or Just Coding With Extra Meetings?
If the answer is 'usually me,' ownership isn't distributed yet
If it's always me presenting, the team isn't building incident-response muscle
The honest answer tells you how much you're still the bottleneck
Mentorship is the multiplier; code review alone is quality control
The second instinct is the one that scales past your own hours
Lesson Learned
Thakur Ganeshsingh
The lesson that has stuck with me the longest: an 85% drop in downtime looked, from the outside, like an engineering achievement. From the inside, it was a leadership one. I didn't get better at debugging during those two years - I got better at making sure debugging wasn't only my job. That's the actual skill a hiring manager should be evaluating when they look at this role: not whether I can fix hard problems, but whether I can build a team where hard problems get fixed without me.
What This Means Going Into a Management Role#
For anyone evaluating me for an engineering-management role based on this experience, here's the honest summary: I inherited a team that measured me by how fast I could personally solve things, and the hardest part of the job was deciding to stop optimizing for that metric. The 85% downtime reduction is real, it's documented, and it's traceable to specific changes in ownership structure, postmortem practice, and mentorship investment - not to a burst of personal output.
That's the version of "ownership" this role actually taught me: not owning every outcome myself, but making sure every outcome had a real owner who wasn't me.
Next in this series: "Leading Without Reports: Running a 5-8 Person Advocacy Team at Freshworks" - what changes when you have accountability for outcomes but no formal authority over the people who need to deliver them.
Have you gone through a similar shift from top individual contributor to team multiplier? I'd genuinely like to hear how you navigated it.
