Why I Left a Large Company for a Startup

Leaving PhonePe did not make my workload lighter.

It did the opposite.

I moved to a smaller startup, took on more responsibility, and started working across systems I had barely touched before.

That was exactly why I left.

I joined PhonePe straight out of college.

For the next two and a half years, I worked on infrastructure behind one of India’s largest payment platforms.

That kind of scale changes how you think.

A small mistake is rarely small.

A bad configuration, an unsafe deployment, or one overlooked failure mode can affect a massive amount of traffic.

You learn to respect production very quickly.

At PhonePe, I worked deeply on the Layer 7 infrastructure.

That included Nginx, proxies, content delivery networks, API gateways, traffic routing, automation, and databases such as Aerospike and MariaDB.

The infrastructure was largely on-premises.

There were fewer managed services hiding the lower layers from us.

So when something broke, I had to understand what was happening across Linux, networking, proxies, databases, and the application path.

That depth was incredibly valuable.

I did not just learn how to edit an Nginx configuration.

I learned how traffic moved through the system.

I learned how a proxy behaved under load.

I learned how one change could affect latency, availability, and the blast radius of a failure.

I also learned what production mistakes feel like.

I caused issues.

I saw outages.

But the culture around those incidents mattered as much as the technical lesson.

My managers did not turn every failure into a blame game.

The focus was on understanding what happened, reducing the impact, and preventing the same class of failure from happening again.

That taught me something early in my career:

Production responsibility grows faster than technical confidence.

The more you learn, the more carefully you operate.

But after a couple of years, another problem started becoming visible.

I was learning deeply, but inside a relatively narrow slice of infrastructure.

I had become comfortable with Layer 7 systems.

Nginx changes felt familiar. Proxy debugging was no longer intimidating.

Many operational tasks had started becoming muscle memory.

That comfort was useful.

But it was also a signal.

Early in my career, I did not want to know only one part of the infrastructure stack extremely well.

I wanted a wider view.

PhonePe had built many internal platforms for its own scale and requirements.

That made complete sense for the company.

But it also meant I had limited exposure to some of the technologies being used across the broader market.

Kubernetes was one of them.

Cloud infrastructure was another.

I understood production systems, but I had not yet built and operated enough infrastructure on AWS, Google Cloud, or Azure.

I had not managed enough Kubernetes clusters end to end.

I had not owned the full path from provisioning a resource to migrating a workload and operating it afterward.

That gap started bothering me.

So I began learning Kubernetes outside work.

I studied after office hours, built things myself, and completed the Certified Kubernetes Administrator certification.

The certification was useful.

But more importantly, it confirmed that I wanted to work in an environment where Kubernetes and cloud infrastructure were part of my daily job, not just something I studied on the side.

Then a recruiter from Prophecy reached out to me on LinkedIn.

The interview process had around five rounds.

There were Kubernetes discussions, system design questions, and deep conversations about the infrastructure I had worked on at PhonePe.

That depth helped me.

Even when I did not know every technology they used, I could explain how real systems behaved under load, what failed in production, and why certain design choices mattered.

That is one advantage of going deep early.

The exact tool may change.

The underlying engineering instincts carry forward.

I eventually joined Prophecy as an SRE 2.

Prophecy is a much smaller company, with roughly 150 to 160 people.

The working style was completely different.

At a large company, infrastructure is usually divided across specialized teams.

At a startup, the boundary often becomes: This needs to work. You own it.

That meant more responsibility.

It also meant more freedom.

I could work on infrastructure across AWS, Google Cloud, and Azure.

I could participate in database migrations, image migrations, cluster setup, automation, and cloud resource provisioning.

Instead of owning one mature layer, I was now touching a much wider part of the system.

The trade-off was obvious.

At PhonePe, I had operated mature infrastructure at enormous scale.

At Prophecy, I was helping build and improve infrastructure that was still evolving.

There were more things to understand.

More decisions to make.

More places where I could be wrong.

But that was the kind of pressure I was looking for.

I did not leave because the previous job was bad.

I left because it had already taught me what I needed most at that stage.

It gave me depth.

The startup gave me breadth.

Of course, compensation was also a factor.

You cannot completely separate career decisions from money.

Your responsibilities grow, your life changes, and your compensation should grow with them.

But money alone was not the reason.

A higher salary would not have been enough if the role had offered the same kind of work.

The real reason was ownership.

I wanted to move closer to the decisions.

I wanted to build more systems from the beginning instead of only operating mature ones.

I wanted to see how infrastructure choices were made before they became standards.

Neither large companies nor startups are automatically better.

They optimize for different things.

A large company can teach you scale, specialization, strong processes, and the cost of getting production wrong.

A startup can teach you breadth, ambiguity, ownership, and how systems are designed while the requirements are still changing.

The right choice depends on what you are missing.

At that point in my career, I was not missing scale.

I was missing breadth.

So I chose the harder workload because it came with a wider learning surface.

Sometimes growth is not about finding an easier job. It is about choosing a harder problem that teaches you something new.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.