By Tanmay Kumar Pandey | AGMP 2025

If I had to describe my career honestly, it would be this:

I was rarely ready for the role I was in—but I was already doing parts of it.

On paper, it looks structured. Developer, lead, architect, cloud, and now working at the intersection of systems and AI.

But that’s hindsight.

While it was happening, it felt much messier.

I was writing code while running Scrum ceremonies.
Designing systems while still debugging production issues late at night.
Leading teams before I really understood what leadership actually demanded.

Nothing changed cleanly. Things just… overlapped. Stepping Into Gaps (Before It’s Called a Role). I started as a developer—Java, microservices, enterprise systems. Early on, progress was straightforward. You solve problems, you learn the system, you take on more complexity.

But over time, I kept getting pulled into things that weren’t strictly “development”:

• discussions that were going nowhere
• teams blocked not by code, but by coordination
• inconsistent ways of working that slowed everything down

I didn’t step into those because I had to. I stepped in because someone had to.

That’s how I found myself doing a bit of everything—coding, facilitating, structuring work, pushing for better practices. At that point, I didn’t think of it as a transition. I thought of it as “just helping things move.”

The Mistake That Took Me Time to Notice

When I moved into leading teams, I carried forward the same instinct that had worked for me as an engineer:

If something is important, I should stay close to it. So I did.

I reviewed almost everything that mattered. I stepped into critical issues early. I made sure nothing went out unless I was comfortable with it. And to be fair—it worked, for a while. Delivery was stable. Quality was high. Stakeholders were satisfied. But slowly, something started feeling off. I was constantly stretched. The team was capable, but not really taking ownership. And despite all the effort, we weren’t getting faster.

There wasn’t a dramatic failure that forced this realization. It was more uncomfortable than that—it was a pattern. Everything depended on me more than it should have. That’s when it hit me: I wasn’t leading the system. I was the system.

Learning to Step Back (Without Stepping Away)

Fixing that was harder than I expected.

Delegation sounds simple when you read about it. In practice, it means letting go of control in areas where you’re used to being right. I had to consciously change small things:

• not jumping in immediately when something looked off
• letting decisions happen without my involvement
• accepting that others would approach problems differently

There were mistakes. Some avoidable, some necessary. But over time, the shift became visible:

• people started owning outcomes, not just tasks
• decisions moved faster without waiting for me
• the team actually became stronger without me being in the middle of everything

That was probably my first real lesson in building systems that don’t depend on a single person.

When the Nature of Problems Changes

Around this time, my work started expanding beyond application development. Initially, it was just helping out—reviewing deployments, troubleshooting environment issues, supporting DevOps teams when things got stuck. There was no formal shift into cloud. But gradually, the scope changed.

I started getting involved in:

• cloud architecture decisions across Azure and GCP
• migration strategies for existing systems
• infrastructure and reliability concerns that went beyond code

Eventually, this became a significant part of my work—leading cloud migrations, working on platforms like Kubernetes and OpenShift, and thinking about systems end-to-end.

The shift was subtle but important: I stopped thinking only about what the system does, and started thinking about how it behaves in the real world.

Building Systems… and Then Explaining Them

Somewhere in the middle of all this, I also co-authored a book on Cloud Computing and Big Data. At first, it felt like a separate track. But looking back, it was deeply connected to what I was already doing. Writing the book forced me to:

• take messy, evolving concepts and make them structured
• align across multiple contributors with different viewpoints
• simplify without losing depth

In many ways, it felt like leading an engineering system—just in a different form. It made one thing very clear to me:

Understanding something deeply is one thing.
Making it understandable to others is another skill altogether.

Where It All Comes Together

My current role has pushed all of these threads together.

Working on large-scale cloud onboarding and migrations—across hundreds of applications, multiple clouds, and different client environments—changes how you think about decisions.

At that scale:

• small inefficiencies don’t stay small
• architectural choices have long-term consequences
• and you don’t get the luxury of perfect information

You have to decide anyway.

And you’re accountable for how those decisions play out—in cost, in reliability, and in whether people can actually work effectively on the systems you design. This is also where earlier lessons become non-negotiable. You cannot operate like the early version of yourself who tried to stay close to everything. It simply doesn’t scale. Looking Back, What Actually Changed? From the outside, it might look like I moved across roles. But internally, the changes were different:

• from solving problems myself → to enabling others to solve them
• from focusing on code → to thinking in systems
• from holding control → to designing for autonomy

None of these happened overnight.

Most of them happened because something stopped working—and I had to adapt.

Designing in Motion

Today, my career looks intentional.

It didn’t start that way. It was shaped through:

• stepping into things before I felt ready
• making mistakes I didn’t immediately recognize
• and gradually learning to operate at a different level each time

If there’s one thing I’ve learned, it’s this:

You don’t need to have everything figured out.
But you do need to pay attention to what is no longer working—and be willing to change it.

Because sometimes, growth isn’t about adding more.

It’s about realizing that what got you here won’t take you further—and having the willingness to let it go.

Author bio: 

Tanmay Kumar Pandey works at the intersection of engineering, cloud, and large-scale system delivery, with 9+ years of experience across software development, DevOps, and enterprise modernization. At DuploCloud, he leads client-facing cloud onboarding and migration initiatives in a product-led environment and builds AI-driven DevOps and MLOps systems. An AGMP alumnus from the Indian Institute of Management Ahmedabad, he focuses on building scalable systems aligned with business outcomes and is co-author of a textbook on Cloud Computing and Big Data.