Make yourself replaceable, then move

The career advice I got early on was to make myself indispensable. The most useful thing I've done, repeatedly, is the opposite.

At my first startup, a six-person company building point-of-sale software, I ended up mentoring thirty operations agents as we stood up an enterprise practice for clients like Indian Railways. There was no playbook, so writing one was the job: how to onboard a client, what breaks, who to call. The test of the playbook wasn't whether I could run it. It was whether someone three weeks in could.

Years later at Juspay, the pattern repeated at higher stakes. I co-founded Hypercheckout and ran it through its growth years. The last thing I did before moving on wasn't a feature or a deal. It was mentoring a program manager and four operations teammates until they fully owned the product's day-to-day, and then actually letting go.

Why hoarding feels safe and isn't

Holding irreplaceable knowledge feels like job security. It's actually a ceiling, twice over.

It caps the product, because anything routed through one person's head has that person's bandwidth as its throughput limit. And it caps you, because nobody hands a new charter to the person who is load-bearing for the old one. Every interesting thing I've gotten to do came after I made the previous thing run without me.

Ownership transfer is a product problem

The naive version of handoff is a documentation dump and a goodbye lunch. It fails the same way bad onboarding fails: it transfers information, not ownership.

What worked instead looks suspiciously like product design:

Shrink the surface first. Before handing Hypercheckout over, we automated the support load down, including an AI chatbot that cut response times in half. You hand off a tractable job or you hand off a fire.

Transfer decisions, not tasks. Tasks delegate easily; judgment doesn't. The shift happens when you stop saying "do this" and start asking "what would you do?", and then, critically, let their answer stand even when yours was slightly better.

Make the new owners visible. People grow into ownership faster when everyone else treats them as the owner. That means routing questions to them in public and resisting the gravitational pull of "let me just handle this one."

The community connection

I later learned this is also how open source communities work. A project where only the core team can answer questions has the same ceiling as a product that only its founder understands. The healthiest thing in a community is the moment a question gets answered well by someone who, six months ago, was the one asking.

Whether it's an operations team in Bengaluru or strangers in a GitHub discussion, the mechanism is identical: growth is ownership transferred, on purpose, to people you've prepared. Make yourself replaceable. Then go do the next thing.