Five Years, Eight Managers, One Company
Today marks five years since my first day at Razorpay, my first and only job. People keep asking how I stayed this long. I think it comes down to five rules.
Today, the 19th of July 2026, I complete five years in my career. All of it at one place.
I graduated from NIT Silchar in 2021, got hired on campus by Razorpay, and started working on the 19th of July that year, from my bedroom, because it was still the pandemic and offices were a rumour. Five years later I’m still here, which apparently makes me something of a curiosity. People ask me, with varying degrees of politeness, why and how I stayed in one company this long. The unspoken part of the question is usually didn’t you get bored? or sometimes couldn’t you leave?
The honest answer is that “one company” is doing a lot of work in that sentence. I’ve changed teams so many times that my current manager is my eighth manager in the org. I’ve worked across multiple domains, multiple products, multiple codebases. In terms of variety, I’ve probably had three or four jobs; they just all happened to send the same company’s name to my bank account.
But there’s more to it than that. Looking back, I think there are five rules I followed, mostly without realising I was following them. Here they are, written down properly for the first time.
Rule 1: Do not get attached to your code
This is the big one.
Eight managers means seven goodbyes, and that’s just the managers. Team members left. Good friends left. Products got reprioritised, teams got reshuffled, systems I’d poured months into got handed over to someone else. I left too. I mean, I moved. Again and again. Things kept changing, because things always keep changing, and no amount of attachment slows that down.
Early on I decided to stop fighting it. I calmly accepted whatever was thrown at me. New team? Sure. Unfamiliar domain? Okay. Codebase nobody wanted to touch? Hand it over. I said yes to all of it and delivered everything with whatever capability I had.
The funny thing is what happened as a side effect: I became known as a Swiss Army knife. The person you could drop into almost anything. That reputation turned out to be worth far more than being the world expert on one service that might not exist next year.
Your code will be rewritten. Your team will be reorganised. What survives is what you learned and who you became while writing it. Get attached to that.
Rule 2: Empathy
Give that KT. Help that junior. Help that teammate who’s stuck. Answer that cross-functional friend’s doubt even though it’s not your problem. Review that PR properly instead of dropping a lazy approve.
Help everyone, selflessly, without keeping score.
I won’t pretend this is pure altruism (though it mostly is). When you help people freely, you end up understanding more of the system than your own corner. You build a network of people who trust you. And when you are the one stuck at 11 PM during an incident, someone shows up for you too. But even without any of that, it’s just the right way to be. Be the person who is open to helping. It compounds in ways a promotion cycle never captures.
Rule 3: Dedication
I once heard that Teddy Roosevelt gave an entire speech with a bullet lodged in his chest. He opened with, more or less, it takes more than that to kill a Bull Moose, and kept talking for an hour.
I am not asking you to do that. Please do not do that.
But you do have a responsibility towards your job. Be responsible. Be sincere. Deliver your tasks on time, and when you can’t, say so early instead of going quiet. Managers (all eight of mine, in my experience) love people who can simply get things done. Not the flashiest people, not the loudest people. The reliable ones. Reliability is a superpower that’s disguised as a boring trait.
Rule 4: Keep learning, ask dumb questions
Forget your ego. Ask what you do not know.
Every time I moved teams (and as established, that was a lot), I was the new person all over again. New domain, new jargon, new tribal knowledge. The fastest way through that is to ask questions that feel embarrassingly basic. What does this acronym mean? Why does this flow exist? What happens if this job runs twice?
A lot of dumb questions is far better than confidently delivering wrong code to prod. Especially in payments, where “wrong code in prod” isn’t an abstract concept: it’s someone’s money. The engineers I respect most are the ones who ask the obvious question in the meeting that everyone else was too proud to ask. Half the room is silently grateful every time.
Rule 5: Take care of your health
Both physical and mental. I put this last, but if I’m honest, it’s the one I learned the hardest way.
Burnout is a real thing. Stress accumulates quietly, the way complexity accumulates in a codebase: no single day is the problem, and then one day the whole thing is fragile. Some things at work are simply beyond your control: reorgs, market conditions, decisions made three levels above you. Let them go. Be a stoic about the things you cannot change, and spend your energy on the things you can.
Keep things fresh. Move your body. Log off. Some things are beyond your control; let go.
Sigh. I’ll be honest with you: I have been tired for the last five years.
Lately, though, I’ve realised something that took me embarrassingly long to see: the job cannot be the whole life. So I’ve started exploring things outside of work. Personal projects, like the site you’re reading this on. Writing novels. Reading novels. Watching anime. Going to the gym. Small things that are entirely mine, that no reorg can take away.
Keep yourself motivated and happy. That’s the real rule zero, hiding under the other five.
Here’s to the last five years: all eight managers, every team I passed through, and everyone who left and everyone who stayed.
Peace.