They Call Me Cheetah

I’ve started watching movies and TV shows again, and as someone who’s really into the art, I notice everything: the light, the music, the subtle details, the aesthetic. I sometimes wish our lives had a background score too, something that could hint at where we’re headed.

There are moments that don’t feel significant while you’re living them. You don’t realize you’re standing at an intersection. And, as I said, there’s no dramatic music in the background. Nobody announces that your life is about to change. Instead, everything feels strangely ordinary: you attend meetings, take notes, send the minutes of meet to everyone, make mistakes, and survive another day.

Only months later, when you look back, do you realize that one decision quietly changed the direction of everything that followed.

The last six months have been one of those moments for me.

When I joined American Express as an intern, I thought I knew exactly what my career was going to look like.

Like most engineering students, I had spent years building a picture of what "real engineering" looked like. My world revolved around code. During college I built full-stack applications, worked with JavaScript and Python, participated in hackathons, freelanced, interned at startups, and spent countless nights debugging projects that nobody had asked me to build except myself. I loved taking an idea and turning it into something people could actually use and also admire the visuals, the frontend not just the functionality.

I assumed my first corporate internship would simply be a larger version of that. I imagined production code, pull requests, APIs, architecture discussions, feature development, engineering design reviews, and learning from experienced software engineers.

Instead, my first few weeks looked nothing like I had imagined.

I sat through knowledge transfer sessions where a lot of the terminology was new to me or at least used in a way I hadn’t dealt with before. Varicent, Incentives, YTD, QTD, Sales compensation. Compensation plans. Payout calculations. Upstream systems. hierarchies, crediting, abbreviations GS, GMNS, GCS, ICS, SPACE.

It felt like someone had dropped me into the middle of a conversation that everyone else had been having for years. As an engineering student with absolutely no finance background, everything was overwhelming.

How does American Express actually make money?

How does incentive compensation work?

Where does all the data come from?

Why are there so many upstream systems?

How does a salesperson's performance eventually become a number inside a compensation report?

None of this had anything to do with what I had spent the last four years learning.

For the first time in a long time, I felt like a complete beginner again. That feeling was uncomfortable.

College has a way of making you confident inside your own bubble. You spend years becoming "the coding guy" among your friends (I am from ece). People ask you for help with projects.

Then suddenly you're sitting in a meeting where someone is explaining compensation models and you realize you don't even know enough to ask intelligent questions.

There was one irony that always made me laugh.

I could build full-stack web applications.

I could automate workflows using Python.

I could design databases.

But I didn't know how to properly use XLOOKUP (I do now though).

Someone asking me to create a Pivot Table made me nervous.

If you'd asked me to build an API, I'd happily do it.

If you'd asked me to summarize an Excel sheet manually, I would quietly open YouTube in another tab.

It was humbling.

At first, I interpreted that feeling as failure. I thought maybe I had taken the wrong turn, I was at the wrong place. Maybe I was slowly moving away from engineering. Maybe everyone else was building products while I was learning spreadsheets. That thought stayed with me for weeks.

Every evening, almost out of habit, I'd open LinkedIn. And LinkedIn has a very interesting way of making you question your own journey. Someone had been selected for Google Summer of Code. Someone announced their Summer of Bitcoin acceptance. Someone became an LFX mentee. Someone had merged their first Linux kernel contribution. Someone had become a maintainer of an open-source project. Someone had solved five hundred LeetCode problems. Someone had joined a cutting-edge AI startup.

Meanwhile, I was learning how incentives were calculated for sales colleagues.

I remember thinking to myself, "Am I falling behind?" It wasn't jealousy. At least, not entirely.

It was something more subtle. It was the fear that I had somehow drifted away from the kind of engineering I had always imagined for myself. I began questioning my own decisions.

Should I have chosen a software engineering role somewhere else? Would six months here make me less employable? Was I slowly forgetting what I had spent years learning?

Looking back now, I realize something important. The problem wasn't my internship. The problem was my definition of engineering.If nobody asked me to write software anymore... Was I still an engineer?

I had unconsciously reduced engineering to writing software. If I wasn't writing production code every day, then I assumed I wasn't growing as an engineer. That assumption would quietly break over the next few months.

The first person who helped me realize I was growing wasn't even talking about code. It was my manager. Every week we'd discuss my progress. I expected feedback about technical skills. Instead, he appreciated something completely different. He told me I learned quickly. He said I communicated clearly. He liked that whenever I picked up a task, I could explain exactly what I was working on, what blockers I had, and when I expected it to be completed. At first I underestimated those compliments.

Communication?

That wasn't engineering.

Ownership?

That wasn't engineering either.

I wanted people to appreciate my coding skills.

But over time I noticed something. The engineers people trusted the most weren't always the smartest people in the room. They were the people everyone knew they could depend on. They communicated. They took ownership. They followed through. That lesson stayed with me.

My director noticed something similar. Whenever he spoke about my work, he rarely talked about technical details. Instead, he described me as proactive. He appreciated that I took ownership. He noticed that I didn't wait for instructions before thinking about the next step.

What surprised me most was that the appreciation came independently from people who had never worked directly with me.

One piece of feedback I got from one of the directors who sits in US who hasn't worked with me directly. It was about my pace. He told me I worked at startup speed. At first I thought he meant I worked quickly. Later I realized he meant something deeper. I didn't wait for perfect requirements. I didn't wait until I knew everything. I built proof of concepts, collected feedback, improved them, and kept shipping.

Again, I didn't fully understand the importance of those words at the time. I thought they were simply nice compliments. I now think they were describing habits that matter far longer than any programming language. Still, despite all the positive feedback, something inside me remained unsettled. I was learning the business. I was learning the tools. I was becoming more confident.

Despite all of this positive feedback, one feeling still lingered.

I missed building.
I missed solving technical problems.

It almost felt as if one part of my identity had been left outside the office every morning.

I did get one opportunity to build something technical. As part of the team under my director, I worked across several subteams, each led by a different manager. After a few months, I was moved to another subteam, where my new manager handed me a problem that had been lingering for nearly a year or two. A senior developer had already looked into it, run a spike story, and concluded that it could not be automated because no API existed. For a while, that seemed like the end of the discussion. But when I joined the team, I was asked to look at the problem again. Instead of accepting the limitation, I became curious. What if the API existed but simply wasn't documented? So using the skills which I had picked when I was doing web development in college, I started looking at the network calls, the requests and responses, the headers, the payloads. I began reverse engineering the system. Eventually, I found what I was looking for. The API had been there all along. Once I understood how it worked, the automation became possible. I automated the triggering of a workflow using Github Actions. I solved this problem in less than a day, left my manager pleasantly surprised. I was proud that I had used my development skills to solve something that others had considered impossible. I thought it was the end of the story, but it wasn't. It was the beginning of a new chapter.

Our entire team, under our VP, was shifted into a new org: the Colleague Experience Group, or CEG. The incentives work wasn't going away, but the context around it was different now. CEG was more connected to how the company thought about its own people and processes.

I didn't fully understand what this meant at the time. I just showed up and kept working.

On one fine morning, I still remember it clearly.

My director texted me at 8am,

"Kapil, do you know Python?" I don't think I've ever answered a question faster.

"Yessir."

He then explained a problem the team was facing. There was a repetitive process that people were doing manually. The work consumed an enormous amount of time. He asked me a very simple question.

"Can we automate this using Python?"

For the first time since joining the internship, everything suddenly felt familiar. It wasn't because the problem was easy.

It was because someone had finally asked me to solve a problem using the skills I had spent years building. I wasn't the engineering student trying to understand finance anymore. I was simply a problem solver again. That evening I built a proof of concept.

Not over the next week. Not after several iterations.

By the end of the day.

I remember the excitement I felt while writing that first version. Not because I was writing Python. But because I could finally contribute in a language I understood. That proof of concept became the beginning of something much larger than I could possibly have imagined At the time, I thought I was simply solving one problem.

I wasn't. I was unknowingly changing the way people around me perceived my role.

The automation itself wasn't particularly glamorous. It wasn't a distributed system handling millions of requests per second. It wasn't an AI model trained on billions of parameters. It wasn't the kind of project that usually makes headlines on LinkedIn.

It was a business problem. A repetitive, frustrating, time-consuming business problem. The kind of problem that quietly consumes hours every single week without anyone questioning whether it should exist in the first place. That project taught me something I wish I had learned much earlier.

Engineering isn't measured by the complexity of the technology you use. It's measured by the amount of friction you remove. I had spent years believing that impressive engineering meant impressive code. Clever algorithms. Beautiful architectures. Fancy technology stacks.

Then I watched a Python script reduce a process that previously required nearly 20 hours for every hundred colleagues to roughly twelve minutes.

Nothing about that sentence mentions algorithms. Nothing about it mentions design patterns.

It mentions time. Time is probably the most valuable thing you can give back to another person.

Nobody walked up to me and said, "Your code is elegant." Instead, they said things like,

"This is going to save us so much time."

"This changes how we'll work."

"How did you build this so quickly?"

That was the moment I realized that businesses don't celebrate code. They celebrate outcomes. Code is simply the medium. The outcome is what people remember.

The project moved much faster than I had expected. What began as a proof of concept quickly turned into something real. More stakeholders became involved. More discussions started happening. People from senior leadership wanted to understand what had been built and how it could be expanded.

As an intern, I got to work on an SVP level initiative. Some of the appreciation came from people I had never directly worked with. Some of it came from leaders sitting thousands of kilometers away. One of the senior leaders based in the UK appreciated the work that had been done and later recognized me through Blue Rewards.

What made that recognition particularly meaningful wasn't the reward itself. It was the fact that interns normally aren't eligible for Blue Rewards. Someone had consciously decided that the contribution deserved an exception. Moments like that stay with you. Not because of the points. Because they tell you that your work travelled farther than you did.

The more interesting part, however, happened after the project had already been delivered. I thought the story had ended. Apparently it hadn't. Once people inside CEG saw what had been done a process that eat dozens of hours every week, reduced to something that ran in the background while you drank your morning coffee, they started looking at their own workflows differently.

Over the following weeks, our CEG department started identifying more and more opportunities for automation.

One problem became five.

Five became fifteen.

Fifteen became forty now.

Eventually there were over fifty different business problems in our backlog that people believed could potentially be automated. Suddenly this wasn't about one successful project anymore.

This had become a capability.

Also around this time, something else was shifting that I wasn't fully aware of. People had started referring to me differently. Not as "the intern." Not by my name, in certain contexts. They had started calling me Cheetah. The VP of the team for whom I did the automation started would call me Champion, and our team of 3 as magicians. It felt deeply validating, the kind of recognition that makes you stand a little taller, because you realize people see the value you’re bringing.

After the first automation project made its way up the chain, something happened that I hadn't anticipated and couldn't have planned for. A proposal was made to senior leadership, the Head of CEG to build a dedicated new team.The idea was to create a dedicated team whose sole purpose would be solving these kinds of problems.

A team of five people whose entire job would be to solve high-value business problems inside CEG using AI, automation, Python, GenAI, and whatever emerging technologies were relevant.

The proposal was accepted quickly.
The team was named the AI and Automation Enablement team. (internally it was called as Tiger Team )

When I first heard about it, I couldn't stop thinking about one question.

Could I be part of it? I eventually gathered enough courage to ask my director. His response wasn't what I expected.

He didn't say yes.

He didn't say no.

Instead, he told me something that I genuinely respected. He said that he only cared about one thing. Whether the best people for the job were sitting in that team. The role would be opened. People would interview.

If my level matched or exceeded the talent available outside the company, then I would earn my place. At first, I wasn't disappointed. I actually appreciated the answer. I didn't want charity. I didn't want to be selected simply because I happened to be there first.

I wanted to deserve it. There is something deeply satisfying about earning an opportunity instead of being handed one. So I went back to work. I stopped thinking about the team.

A few weeks later, my director called me again. The conversation was short.

He simply told me, "I'm putting you in the new team, Don’t tell this to anyone" I don't know whether he remembers that conversation.

I always will.

When I had joined the internship four months earlier, there was absolutely no possibility that my full-time role would look anything like this. When I join full-time in September 2026, I won't be returning to the Incentives team. I'll be joining the AI and Automation Enablement team as one of its five founding members.

I was supposed to work in incentives.

Instead, I was now preparing to join a newly formed team/ Nobody had planned that. There was no roadmap that predicted it. No one had promised it during my interviews. It happened because opportunities changed after people saw what was possible.

For me, that realization was incredibly powerful. Sometimes careers aren't found. Sometimes they're built. I didn't find my dream role.

I created one. There was some luck involved, but there was also a lot of work which I would have done anyway.

I'm 22. This is my first job out of university. And I'm joining a team whose creation was, in part, justified by the work I did as an intern.

I don't say that to impress you. I say it because six months ago, I was sitting in KT sessions not understanding what QTD meant, opening LinkedIn and wondering if I was falling behind, feeling like everyone else had found the right path and I was lost somewhere off the map.

There was no map for where I ended up. I didn't follow one. I made the path as I went.

As my internship approached its end, I began preparing for my final evaluation. I expected technical questions. I expected discussions around automation. I expected people to ask me how I built things. Instead, the conversation became much broader. The panel consisted of my VP, my director and my managers.

The questions weren't easy.

They challenged my thinking.

I answered every question on the spot.

Looking back, I don't think they were only evaluating my technical ability.

They were evaluating judgment.

The ability to explain complicated ideas clearly.

That realization reminded me of something my manager had been telling me since the beginning. Communication matters. Far more than students often realize.

One moment from that evaluation still makes me smile. After everything was over, my director jokingly patted himself on the back for hiring me. Then, turning towards my managers, he laughed and said,

"Kitna kaam karwa liya tumne iss se." Everyone laughed. So did I.

It wasn't just a joke. It reflected how much trust people had placed in me over those six months.

Another comment that has stayed with me came from my VP. He said that what I had achieved during the internship had become a milestone. That I had set a benchmark for future interns. Those words carry weight. Not because they make me feel accomplished. But because they remind me that expectations are shaped by examples. If my work raises the bar for the next intern, then that's something I'm genuinely proud of.

Around the same time, I was also fortunate enough to receive the Jewel Award. Awards are wonderful. Recognition feels good. But if these six months taught me anything, it's that awards are rarely the most meaningful part of the journey. They're snapshots.

The real reward is the person you become while earning them.

When I think back to the beginning of my internship, I see someone who believed he was moving away from engineering. Someone worried that he was missing out.

Someone comparing himself to open-source contributors, GSoC participants, startup engineers and people building exciting products. Today, I think I was asking the wrong question.

I kept asking, "Am I doing real engineering?" I should have been asking,

"Am I solving real problems?" Because engineering has never been about the logo on your laptop, the framework in your résumé, or the repository on your GitHub profile.

Engineering is about reducing friction.

Engineering is about questioning assumptions.

Engineering is about looking at a process that consumes twenty hours and asking,

"Why?"

Engineering is about building something that makes tomorrow easier than today.

Sometimes that means writing a web application.

Sometimes it means training an AI model.

Sometimes it means writing a Python script that quietly saves hundreds of hours inside an organization.

The technology changes. The mindset doesn't.

One lesson has become especially important to me. LinkedIn is wonderful for discovering opportunities and celebrating achievements. But it also has a way of making us compare journeys that were never meant to be compared.

For months I believed that because I wasn't contributing to famous repositories or participating in well-known programs, I was somehow becoming less technical. I couldn't have been more wrong.

Open source creates incredible engineers. So do enterprise systems. So do startups. So do research labs. There isn't one correct path. There are only different classrooms.

Mine just happened to look different from the one I had imagined.

If I could go back and speak to the version of myself sitting in those early knowledge transfer sessions, overwhelmed by finance terminology and wondering whether he still belonged in engineering, I think I would tell him just one thing.

Relax.

You're not moving away from engineering. You're expanding your definition of it. One day you'll realize that writing software was never the goal. Creating impact was. (and you will be addicted to leaving an impact)

Six months ago, I thought this internship would teach me how American Express calculates incentives.

It did.

But more importantly, it taught me something I wasn't expecting.

It taught me that careers are rarely built by following perfectly planned roads. Sometimes they change because you notice a problem that everyone else has learned to live with. Sometimes they change because you ask one extra question. Sometimes they change because you decide to solve one problem really well that others before you thought couldnt be solved.

I started my internship believing I had to find the right role.

I ended it realizing that if you consistently create value, sometimes the right role finds you instead.

And I think that's a much better way to build a career.

Thank you to my buddy, managers, director and colleagues at American Express for making this journey so meaningful and enjoyable. Your guidance, patience, and encouragement have been invaluable.

I'm grateful to my family for their unwavering support, and I'm excited to see what the future holds.

Cheers!