Curiosity-Driven Builder's Journey

In the era of 𝑨𝒓𝒕𝒊𝒇𝒊𝒄𝒊𝒂𝒍 𝑰𝒏𝒕𝒆𝒍𝒍𝒊𝒈𝒆𝒏𝒄𝒆, what remains uniquely valuable about being human? My answer is our lived 𝐞𝐱𝐩𝐞𝐫𝐢𝐞𝐧𝐜𝐞𝐬 and our 𝐜𝐮𝐫𝐢𝐨𝐬𝐢𝐭𝐲.

MTS is changing the org chart. OpenAI's Greg Brockman gave the origin story: "when starting OpenAI, we didn't want to bucket people into researchers & engineers. Alan Kay advised that they used 'Member of Technical Staff' at Xerox PARC, we loved & adopted it."

AI is reshaping the industry at an unprecedented pace. Many of the vectors — level, job family, tenure, knowledge, and skill sets — no longer matter the way they used to. Before that fully arrives, I want to set down what this decade on the corporate ladder actually taught me.

I recently reflected on my decade at Amazon. Whenever people learn I've stayed at one company for ten years, two questions always follow. The first: "What's it actually like?" The second, usually prefaced with a polite cough: "No offense — but why have you changed so many domains and teams?"

My half-joking answer is that my work density has simply run higher than my cohort's: I've spent the whole decade in startup mode, continuously shipping 0→1 products as an intrapreneur (the body of work tells that story better than I can). Five teams, five domains — but one throughline.

So this is an honest retrace of each team change — not a highlight reel, but a look at how the decisions were really made: what I weighed, what I got right, and what I only understood much later. The lens I keep coming back to, and the one I most want to share, is this:

No single move scores well on every axis. The interesting part is which ones you're willing to trade — and that changes as you grow. This first chapter is where I learned the lens existed at all.

A Snapshot of My Work at Amazon

The journey so far, at a glance — each row is a chapter in this series:

My journey timeline — each chapter adds a domain; the hatched stretch is the future, not yet lived.

Day 1: AWS Payments

I joined Amazon on March 14, 2016 — Pi Day, and, fittingly, the day AWS turned ten. Fresh out of school, I was assigned to my first team: AWS Payments, part of the broader Commerce Platform organization.

If you've never thought about how AWS actually charges its customers, that machinery is exactly what Commerce Platform builds. Put simply: it is the platform that bills AWS customers, anchored by a monthly bill run that has to be correct, on time, and at enormous scale. It was a very typical internal platform team — unglamorous from the outside, deeply load-bearing from the inside. Mistakes here are measured in real dollars on real invoices. I came in as a software engineer (SDE I), and I stayed for three years.

If you're curious what the org is really about, VP James Greenfield gave a great public overview of the AWS Commerce Platform in a 2022 Screaming in the Cloud interview.

On the lens above, Payments scored high on scope and leverage in a way I didn't appreciate at first. The learning curve wasn't a new domain so much as a new bar: correctness, idempotency, reconciliation, the discipline of systems where "mostly right" is simply wrong. That bar shaped how I build to this day.

Years later — after I'd left the team — I finally read the popular book Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (DDIA). I recognized, almost page by page, that the problems it describes were exactly the ones I'd been wrestling with day to day in the Payments invoicing domain. I'd been living the textbook before I read it.

In Q2 2018 I was promoted from SDE I to SDE II — the first real validation that I could own ambiguity, not just close tickets.

---

The Project That Closed the Chapter

The last project I led in Payments was the one I'm still proudest of: deprecating the legacy relational database that sat under all of Commerce Platform's business, and migrating its data — with zero downtime — onto a non-relational store, Amazon DynamoDB.

This was not a tidy project. It was a multi-year program spanning many teams across the organization, with a history of failed attempts before us. Migrating a system of record that money flows through, while it keeps serving live traffic, is the kind of work where the interesting engineering and the terrifying engineering are the same thing.

Our team became the first in the organization to move off that database. The outcomes were concrete:

• Estimated ~$8.5M/year in cost savings from tearing down the legacy relational database (MDB).
• Reduced the variance in P99 latency of invoice creation by ~10%.

Being first mattered beyond the metrics — it turned a stuck, "everyone-knows-we-should-but-no-one-has" program into something the rest of the org could follow. That is leverage: the work outlived my involvement in it.

At the end of Q1, once the launch announcement email went out, I did something that surprised even me. I told my manager I'd decided to change teams.

---

Why Leave on a High Note?

It's a fair question — why walk away right after the biggest win? But that's exactly the logic of the curiosity compass. I had just spent three years going from beginner to someone who could lead a flagship migration. The learning curve had flattened. I could see the shape of the next three years in Payments, and while it would be valuable, it would not make me a beginner again. I wanted to be a beginner again.

This was my first time changing teams, and I didn't fully know how to do it. So I did it the way an engineer does: I ran the experiment. As an SDE II, I interviewed with several internal teams and was fortunate to receive offers from a few:

Three offers, narrowing to one real fork — fundamentals vs. frontier.

---

The Real Choice: ECS vs. Alexa

IoT was interesting, but the decision quickly narrowed to two very different futures.

ECS pulled hard on the part of me that loves true fundamentals. It offered a path into low-level virtualization and the chance to contribute to open-source projects in the container ecosystem. On the lens, it scored beautifully on learning curve (bottom-of-the-stack systems I'd never built) and on community (open source as leverage that compounds far beyond one company). It was the "deepen the foundations" bet.

Alexa AI Health & Wellness pulled on something else entirely. It was a greenfield domain and team. When I talked to the hiring managers and engineers, what struck me was how genuinely excited they were about what they were going to build. It sat outside AWS — a chance to explore a completely new space — and it was riding the most exciting technology wave of the moment: NLU, applied AI, and the kinds of consumer applications that felt like science fiction becoming product. It was the "explore a new frontier" bet.

Fundamentals vs. frontier. Depth vs. breadth. Hardening what's known vs. discovering what's possible. The lens didn't hand me an answer — it sharpened the question.

So I did what I'd recommend to anyone facing a fork like this: I talked to tenured people who had seen many such forks, and I listened.

In the end, I chose Alexa AI — Health & Wellness. I wanted to step outside AWS and explore a brand-new space, and I was genuinely energized by NLU, AI applications, and the products that wave was about to make possible.

But here's the part I want to be honest about: choosing one path didn't extinguish the other. I kept my curiosity for open-source contribution and for the low-level virtualization fundamentals alive. I didn't know it yet, but that flame would shape later chapters of this very story. A choice is rarely a door closing — more often it's a door you leave ajar.

---

Lessons From the First Fork

• Leave when the curve flattens, not when the work runs out. There is always more work; there isn't always more learning.
• Finish before you leave. Ship the thing, send the email, then change teams. Endings earn you your next beginning.
• Talk to people who've walked the fork. Tenure is a cheap way to borrow hindsight.
• A decision isn't a deletion. The interests you don't choose can wait for you.

From Fintech's iron discipline to the open frontier of conversational AI — the largest learning curve I could find, on purpose.

---

Zero to One, Inside a Giant

Alexa Health & Wellness was my first time building a brand-new product and carrying it from zero to one. It was a small, neat, startup-like team living inside one of the largest companies on Earth — which is its own peculiar gift: the energy of a garage with the reach of a global platform.

The team had formed quietly in 2018 within the Alexa organization (under a group called Alexa Domains), with a mandate to make the voice assistant genuinely useful in healthcare — diabetes management, care for new mothers and infants, and aging — all of it under the constraints of HIPAA (CNBC, May 2018). The team was led by Rachel Jiang, our org's leader. Its founding cast included Missy Krasner — who had built the healthcare business at Box and earlier worked on Google's first foray into health records — and a sharp product manager, Yvonne Chou, who would become a close colleague.

I joined as an L5 machine learning engineer, working shoulder to shoulder with L7 product leaders and closely with the applied scientist team. This was my first real taste of the research-meets-engineering seam: scientists probing what natural language understanding could do, engineers like me hardening those ideas into something a regulated, real-world product could ship. I'd later write a whole separate post on that tension — here, it was simply daily life.

I stayed about 1.5 years, and in that window we shipped two public releases:

My piece was the multi-turn speechlet for medication management, built on NLU — the back-and-forth logic that lets a person actually converse with Alexa about their medications rather than bark single commands. We partnered with a pharmacy and a hospital. The work was confidential enough that our office floor required special badge access — you knew the project mattered when the building itself treated it like a secret.

---

When Your Code Talks Back

There is a specific kind of joy in this work that I haven't quite found anywhere else: you connect an Echo device, run your build, and then your own code talks to you — answers, asks, clarifies — while you test and debug. Debugging a conversation is a strange and wonderful thing. The system stops feeling like software and starts feeling like a presence in the room.

In November 2019 we launched to the public — the same month Alexa itself celebrated its fifth birthday (November 6, 2019). The work was highlighted in Amazon's earnings results and picked up by media like Forbes and CNBC. It was a genuinely fulfilling stretch.

The most touching proof that any of it mattered came much later. In December 2020, long after I'd moved on, I was messaging with my former colleague — PM Yvonne Chou, by then a Director of Product and later Chief of Staff at AI2. She wrote (original, unedited):

"I am in Los Angeles for the holidays and my brother got my parents a new Echo Show earlier this month. When I got to my parents house, I noticed my brother was logging dirty diaper changes and my dad had medication reminders set up all on his own :) they obviously wasn't our MM ones, but it was fun to see them use the features the team built and I didn't even have to tell them about it.

Happy new year!

-Yvonne"

Strangers, in their own homes, quietly using the category of thing you helped invent — without anyone telling them to. That is the whole job, really.

---

Riding the Technology Cycle

Looking back, the real lesson of this chapter isn't about healthcare at all — it's about where you stand on the technology cycle. Every transformative capability arrives in waves. The dream of a machine you can simply talk to is decades old; what keeps changing is the engine underneath it. In 2019, that engine was still intent-and-slot NLU, and we were doing the heavy scaffolding the next wave would quietly abstract away.

Being early on the curve feels uncomfortably like being wrong: the product is harder to build, the experience is rougher, adoption lags. But early work is rarely wasted — it teaches you the problem so deeply that when the next wave lands, you already understand exactly what it's good for. The conversational-AI dream didn't fail. It was simply early, waiting for the LLM wave to make it effortless.

---

Why the Frontier Cooled

And yet. This was the pre-LLM world, and the gap between the dream and the technology was real. NLU back then still leaned on slots and rule-based design — the scaffolding of traditional conversational AI. Supporting genuinely context-heavy, multi-turn conversation took enormous engineering effort, and even then the experience wasn't as smooth or as forgiving as what today's LLM assistants make look effortless. Product adoption and revenue were, honestly, not yet ideal.

The wider weather was turning too. Big Tech's grand healthcare bets were cooling: Haven — the much-watched alliance of Amazon, Berkshire Hathaway, and JPMorgan, given its name in 2019 — disbanded in 2021, the same year Google dismantled its own health division. Closer to home, leaders began to depart — Missy Krasner left Amazon in October 2020 for a venture firm. I read the signal: my time in this particular space was coming to an end.

So I reached back for the interest I'd deliberately left ajar a year and a half earlier — virtualization and the fundamentals — and made it my next stop. The door I hadn't closed turned out to be exactly the one I walked through next.

---

Two Tickets That Redirected a Career

Worth noting — in 2019 Alexa AI was generous enough to sponsor me to attend two conferences, and neither of us could have known how much those tickets would bend the next few years of my career:

• KubeCon + CloudNativeCon 2019, San Diego — my first in-person immersion in containers and the cloud-native world. I felt the sheer impact and the raw vitality of the cloud-native community up close, and something in me recognized it as home.
• NeurIPS 2019, Vancouver (YVR) — near the end of the year, a chance to stand among academic researchers and feel, directly, where AI was heading next.

I was in Vancouver partly for a more mundane reason — H1B visa stamping — and I spent the trip happily planning my 2020 travels. Such is life: about two months later, the global pandemic began, and every one of those plans dissolved. But the two seeds those conferences planted — cloud native, and the pulse of AI research — would germinate anyway.

---

Lessons From the Second Fork

• Zero-to-one teaches you what no mature system can. Building the first version of something forces every assumption into the open.
• Internal platform → public product. Shifting from an internal platform team to a public product team rewired how I think about users — from SLAs and invoices to delight, trust, and a name customers actually know.
• Be early, but read the weather. Being right too soon — before the technology catches up — feels a lot like being wrong. Knowing when to stay and when to move is its own skill.
• Say yes to the conference, the talk, the detour. The highest-leverage moments rarely announce themselves; two sponsored trips reset my trajectory.
• The interest you kept alive becomes the path you take next. Curiosity compounds quietly, then pays out all at once.

Two chapters in, the pattern was clear: each move traded comfort for a steeper learning curve, and each time, a curiosity I'd refused to abandon lit the way to the next door.

---

Choosing Essential Infrastructure

With the conversational-AI chapter closing, I finally followed the interest I'd kept alive since the very first fork: virtualization. But I was also deliberate about where. I wanted to land somewhere that was essential, must-have infrastructure — with stable profitability and strong cash flow. In any climate, the unglamorous-but-indispensable layer is the safest place to do ambitious work.

That pointed me straight at containers. I reached out to a manager I'd known, Mats Lanner, who led AWS Fargate — a flagship product of AWS, launched at re:Invent on November 29, 2017. Fargate was on a strong growth trajectory as a serverless container compute platform.

When I reconnected with Mats around July 2020, his reply was more exciting than I'd expected — it was the first time I heard about project "Fusion," the code name for what would become AWS App Runner:

"It's all goodness for us, as Elastic Beanstalk has joined our org and we are doing an exciting project with them this year. This is a S-team goal for us, targeting a re:Invent launch and we think it will change how customers think about running applications on AWS. The project is code named Fusion and builds on top of Fargate..

Sound interesting?"

He also recommended I talk to Archana Srikanta, a senior engineering leader and one of Fargate's founding engineers — someone I already admired (she'd be promoted to Principal Engineer in 2021). I'd watched her YouTube talks on Fargate before I ever joined. We spoke over Chime; she sketched the project at a high level, and we ended up geeking out about Rust. All of it sounded cool. So I joined.

---

Joining the Away Team: Project Fusion

I came on as a direct report to Mats (my L7 manager) on the cross-organization project "Fusion" — later launched publicly as AWS App Runner.

A lot of people worry about being assigned as an "away team" member embedded in another org — especially on day one. As a junior engineer, I felt that same uncertainty. But that worry was slowly replaced by new knowledge, new technology, new discussions. Doing the task in front of you well is the one certain path to dissolving uncertainty. In the end, the away team turned out to be one of the most rewarding bets of my career.

I mainly designed and authored the dataplane, partnered with Amit Gupta, a strong senior engineer from Elastic Beanstalk (he'd go on to make Principal Engineer in Q2 2022). Together we worked through a stack of hard problems:

• Single-digit-second auto scaling
• Multi-tenant request routing
• Cellular architecture
• Capacity management
• Load balancing
• Networking

App Runner also put me in close, daily orbit of three Principal Engineers — Archana Srikanta, Onur Filiz (later a Principal Software Engineer at Microsoft), and Amit — a technical bar higher than any I'd worked under before, and one that pulled my own engineering up fast.

The Containers org was also relatively small compared to giants like Devices or Commerce Platform. For a long time I heard it simply didn't hire at L4 — a deliberate way to keep the bar high, since we were genuinely working on low-level systems.

Along the way I got to explore a lot of new techniques and open-source projects — Kafka, Envoy Proxy, Protobuf, gRPC — tech stacks that weren't yet widely used across Amazon; the Envoy work also had me writing C++. (I'd go on to start the first Envoy Proxy community inside Amazon.)

We launched AWS App Runner on May 18, 2021 (AWS News). It was my first time incubating and launching an AWS public product from zero to one — something worldwide users could discover and use right inside the AWS Console.

Our VP, Deepak Singh, also spoke publicly about App Runner around the launch. Deepak was a leader I followed closely during my containers years — every Friday, end of day, he sent out weekly notes with his thoughts and observations, and I genuinely enjoyed reading them.

---

A Fork: Stay With the Product, or Return?

As an away-team contributor, I eventually hit the obvious question: where do I belong? Mats initially assigned me to help with AWS Fargate's dataplane and Firecracker microVM work, while I kept closing out post-launch items on App Runner.

Then, in a regular 1:1, App Runner's General Manager — L7 leader Prashant Prahlad (now a VP at Datadog) — extended an offer: stay in App Runner as a founding member and core builder.

The same shape of fork as before: the new product I'd built, or the team I'd originally joined.

I chose to stay: I formally joined App Runner as a core member of the team and moved to report to Prashant.

---

The Path to L6: Into Observability

The unavoidable next topic was my own growth. I'd been SDE II since 2018 — nearly three years. Prashant offered me a few projects from the 2021 OP1 roadmap, and I picked a public feature release in Observability. I chose it because I wanted to ship public features; I had no idea how far that single choice would carry me into industry exposure.

The task: give App Runner real observability. We already had metrics and logging; as a one-stop container compute platform, we wanted tracing too. It was a relatively new domain for me, and I spent a lot of time more or less single-handedly on the research and initial build — OpenTelemetry, AWS X-Ray, Grafana.

It pulled me into a remarkable orbit of people: Principal Engineer Jaana Dogan (who later returned to Google as a Principal Engineer), Michael Hausenblas, and Alolita Sharma — genuine experts and leaders in the space — and deeper into the CNCF community. My mentor at the time, Phil Estes (Principal Engineer on the containerd team), knew them all — and it was Phil who later recommended me for the CNCF Ambassador community. Late at night, I worked through the PRFAQ and the customer experience with our PM Akshay Ram.

I led the feature launch in Q1 2022 — and was promoted to SDE III (L6) at the same time.

---

Stepping Into the Spotlight

Then something I didn't expect. Adam Keller invited me onto the AWS Containers YouTube show "Containers from the Couch" to talk about the feature, and the work was highlighted in AWS Open Source News and Updates, #113 that May, and championed publicly by our L7 product leader Shubha Rao (who later joined Google as Director of Product Management, AI/ML). It was the first time I was visible to a public audience because of a product I'd built.

A small side episode: on the day of the podcast, my laptop died. I was anxious and messaged Adam; he messaged back that he'd open the show solo for the first few minutes and could wait for me to restart. To my relief, the laptop came back, I jumped on, rescued Adam from a solo show, and started sharing what we'd built.

From there it snowballed. Public exposure brought visibility — and responsibility. I worked with our GTM, Sales, and Product teams to bring the product to customers and users, co-presented at DockerCon with Inbal Shani (now CPO at Twilio; former CPO at GitHub; our former GM at AWS), and wrote AWS blog posts. I took an internal course and earned a public-speaking certification to represent and support Amazon at top-tier external conferences and events. It felt a little like being on a press tour. I even began getting book-authoring invitations from publishers like Packt, more than once. I summarized that year's work in a Medium post, in list form. It was, without question, a major boost to my career. I gained external connections through it, too.

That community recognition culminated in something I'm still proud of: in late 2022 the Linux Foundation appointed me a CNCF Ambassador. I was invited to the New Ambassador announcement at KubeCon Amsterdam 2023, where I finally met — in person — many of the high-profile builders I'd only ever watched on YouTube and podcasts in the open-source and cloud-native world.

---

Overwhelmed — and a Cooling-Off Period

Visibility has a gravity of its own, and for a while I let it pull me. After my L6 promotion I became a core engineer and a cross-cutting “uber” tech lead — a force multiplier across the App Runner organization (~70 people). At the peak I was overseeing the execution of more than ten project lines as tech lead, and mid-year I also picked up direct reports — both interns and full-time engineers. I literally kept a weekly breakdown of where my hours went. The role stretched well beyond code into deep cross-functional partnership: I authored PRFAQs, worked with sales and GTM, and ran a WBR / MBR (Weekly / Monthly Business Review) with the product team. Big scope, big visibility, the energy of an early-stage startup — and, honestly, overwhelming.

My calendar was “quadruple-booked” more often than not, and bandwidth — not effort — was the real constraint. So when Jason later asked whether I'd take on the Bar Raiser program to support more interviews, I said no. Protecting a reasonable time distribution had quietly become more important than adding another hat.

The org around me was shifting too. Several leaders I'd grown with departed — Inbal, Shubha, Onur, Akshay, Prashant — and a reorg landed. By then Compute Services had grown into the larger DECS org (Developers, Events, Containers, and Serverless), and App Runner was folded into AWS Lambda. We got a new L7 manager, Jason Woodlee, who'd spent years as a CTO at an East Coast startup. He brought a different culture, and it felt refreshing.

My interns accepted the return offers we'd extended, and I'd hired a new full-timer — by every external measure things were going well. But I sensed it might be time to stop. I raised the decision to leave with Jason. He wanted me to stay, and generously offered to work on my Principal Engineer path together, documentation and all. I declined.

The honest reason: the business value no longer felt proportional to the hours I was pouring in. I needed a balance, or a break. (That App Runner later settled into KTLO — keep-the-lights-on — mode only confirmed the instinct.)

A Word on Product Positioning

There's a running joke that AWS has "17 ways to run containers." It's funny because it's true — and it points at something real: finding the right position for a product matters as much as building it. App Runner, for all the engineering we were proud of, never found the adoption curve that its closest analog, Google Cloud Run, did.

That stings, because App Runner was the first AWS product I helped build from zero to one. But failure is the mother of success — you only collect the lesson if you actually believe that. Still, when I left, I was genuinely lost about where to go next.

---

Lessons From the Third Fork

• Bet on indispensable infrastructure. Essential, profitable, cash-generating layers are where ambitious work is safest and compounds longest.
• Away-team anxiety dissolves in the work. Uncertainty shrinks every time you ship the task in front of you.
• Adopt the tech the rest of the org hasn't yet. Envoy, gRPC, OpenTelemetry — being early inside a big company is its own kind of edge, and its own community.
• Build the product, then tell its story. Visibility followed the work, not the other way around — and the storytelling became a second skill.
• Know when to stop. Scope and visibility can outgrow the value they create; walking away at the right time is a skill of its own.
• … but don't stop too early. Honestly, I think I left App Runner a little too soon. Even as a founding member, there was still room to grow — and staying through my L6 promotion would have made building a solid L6 profile smoother. My early exit, plus an end-of-year team change, quietly dented my rating, and I didn't appreciate at the time how much that mattered. If I could choose again, I'd lean on the leverage I'd already built and let good momentum run until a real hard stop forced the move.
• Positioning is half the product. The best engineering still needs the right place in the lineup to win adoption.

Three chapters in, my career had stopped looking like a ladder and started looking like a series of deliberate forks — each a steeper climb, chosen on purpose.

---

A Mistake I Had to Make

Lost and a little depleted, I made what I now consider a career mistake — and one I'd probably make again, for what it taught me. I joined Amazon S3.

If you use AWS at all, you know S3. It was the very first AWS product, launched on Pi Day in 2006 — the same calendar date I would later join Amazon — and it is still the foundational data service of the cloud, the largest-scale data service on Earth (500T+ objects, 200M+ requests/sec, exabytes of data, 123 AZs, 39 Regions — at its 20th birthday). At the time — and still today — it is led by VP Mai-Lan Tomsen Bukovec, and long before I joined I'd read a great deal of her writing, internal and external. She is a passionate and deeply capable senior leader — and one of the most prominent female and Asian leaders at AWS.

Learning From Mai-Lan

Mai-Lan has a famously well-formed body of theory and practice for running a mature organization — including a crisp, widely-circulated definition of the roles of Principal and senior IC leaders. Where Deepak Singh's much-loved Friday notes were a stream of informal thoughts and observations, Mai-Lan's was a fully shaped system.

She hosted monthly leadership learning sessions across the S3 org and encouraged every L6+ leader to attend and discuss. Her TA would prepare each session's topic — usually one of the Leadership Principles — along with supporting docs shared ahead of a genuinely formal discussion. I attended most of them, and spoke once myself — the topic that session was “Recognizing Critical Moments.” By coincidence, one of the other speakers that day was Bryan Liles — the Senior Principal Engineer (L8) at AWS, and previously a high-profile figure in the CNCF community — who had joined S3 the very same week I did. Watching a mature, VP-level leader articulate her point of view and deliberately grow younger leaders was enormously valuable to me.

The Mistake Underneath

For all that organizational polish, you still can't escape the fact that line managers vary in caliber. When I was choosing my new team and talking with the hiring manager, I failed to do the expectation-setting I should have done. I went from reporting to an L7 manager as a tech lead to a new team reporting to a junior line manager — a serious downgrade in both scope and position. At the same time, I overestimated the career maturity of that junior manager, who had just transitioned from an IC into a management role.

And I couldn't blame anyone but myself. The leverage and standing I'd had in App Runner were things I had earned there, and the move was my own decision. From the new manager's vantage point I was simply a newly promoted L6 IC — he had no reason to account for the unusual density of work and delivery I was used to. The combination was never going to fit.

A Quick Course Correction

I recognized the mismatch almost as soon as I arrived, and I moved fast. My former App Runner manager had, as it happened, moved into a different S3 division around the same time — so I moved to report to her again. That was the real starting point from which I began to understand how a hyperscale product organization actually works, in contrast to the smaller, startup-shaped world of App Runner.

---

Landing in S3 Index

The team I landed in was S3 Index. Our Director, Amy Therrien, laid the business out clearly in a re:Invent talk; in short, we work on reducing 503s — the slow-down and throttling errors customers can hit at scale. Worth noting: viewed as a standalone product, S3 Apex (API + Index) would rank among the top-20 revenue businesses at Amazon — and it is, of course, a tier-1 business for S3.

RocksDB, Meta, and a 10-Year-Old Database

Because of my background — and a recommendation from my manager, who knew it — I got a genuinely unique assignment: a cross-company collaboration with Meta, deep-diving the open-source LSM-tree database RocksDB (which, fittingly, turned ten that same year). We held weekly syncs with the Meta / RocksDB engineers, working in C++ — the same language as my Envoy days. Database engines weren't my home turf, but that was rather the point: it was a great thing to learn.

Our sister team in London had handed this part of the business over to Seattle, so we also met regularly with colleagues across London and Europe — a genuinely interesting cross-timezone collaboration.

One small marker of how alive this corner of the industry was: the RocksDB team's company, Rockset, was acquired by OpenAI on June 21, 2024.

---

2023: Reading the AI Wave

2023 turned out to be a special year. ChatGPT had landed on November 30, 2022, and the whole world began to stir. Having already lived through the conversational-AI hype once, I chose a deliberately observant, conservative stance — it might, I thought, be just another cycle peaking early, the way voice AI had.

What changed my mind was a signal from inside, not the headlines. Deepak Singh — by then VP of the broad DECS org (Developers, Events, Containers, and Serverless) — moved to report into Swami Sivasubramanian, VP of AI & Data, to take charge of AWS CodeWhisperer. (Swami did his PhD at Vrije Universiteit Amsterdam, mentored by AWS CTO Werner Vogels; one of Amazon's youngest VPs, he joined the company's S-team in September 2023.) When a leader of that scope re-points his own career at generative AI, it stops looking like hype. That was when I realized this wave was real — and that it was time to pay serious attention.

The Goal: Find a GenAI Team

From there the goal was clear: find a GenAI team to join. As always, it was a bet — and this one didn't go smoothly. Because the rise of GenAI was unplanned for everyone, the company included, Swami's org was in continuous reorg and resource-shifting mode. Most teams had frozen hiring until the dust settled, and when a team was short on people, the usual move was simply to shift engineers over from another product — early Bedrock, for instance, was staffed largely with engineers from Lex. And there was a long queue from outside the org, too: everyone wanted into this frontier domain.

For a while it felt like there was simply no way in for someone from outside that org, and I nearly gave up. But then a turning point appeared. (A rule I keep: when you're about to give up on something, give yourself three more months first.)

Three Offers

The turning point came as three offers, all in GenAI:

Three offers, all in GenAI.

The route there was a little unusual. I'd interviewed for Bedrock Fine-tuning and finished the informal loop, but the hiring manager came back to say the headcount had been filled. Rather than leave it there, he recommended me to two sister teams that did have open headcount — Bedrock Agent and Bedrock Inference — and because I'd already completed the informal loop, I didn't have to run it again for either.

And so the tradeoffs lined up again — three different GenAI bets, each with its own emphasis and its own hiring manager (an L6 (M2) at SageMaker AI Optimization, an L7 at Bedrock Agent, and an L6 (M1) at Bedrock Inference). After the scope lesson S3 had just taught me, reporting level was no longer an abstraction — it was one of the things I now weighed carefully.

I chose Bedrock Inference. My thinking was to enter at the bottom of the stack — start from the most foundational layer and build up. Looking back today, I'll be honest: I lacked prescience. I walked right past Bedrock Agent, which in 2025 was reformed into Swami's new Agentic AI org — and three years on, agentic AI has become one of the hottest practices in the entire LLM field. The fundamentals were the right instinct; I just didn't see how fast the frontier above them would move.

---

Engineer No. 2

The Inference team was newly funded when I joined. I was the first engineer hired, alongside one L6 engineer who'd come over from Lex — which made me, in effect, engineer No. 2. It was a privileged and confidential project: building the inference engine for Anthropic's models on Bedrock.

So, once again, I was a core founding engineer building from scratch — clean code, high visibility, fast pace. Another startup, this time inside the most important business at the company. And it grew like one: from 2 people to 50+ in a single year. (I wrote up that first year in more detail here.)

Building With Anthropic

We partnered directly with Anthropic — including co-founder Ben Mann — with 2+ working sessions a week and a monthly happy hour for each new model release. That work touched a number of ideas that have since become well-known standards across today's open-source inference community — disaggregated inference, multi-node inference, context-aware routing, and prompt caching.

Day-0 Launches & Trainium

Through 2024 I led almost all of Claude's Day-0 public releases on Bedrock — including Computer Use, Anthropic's first agentic-AI feature, on Claude 3.5 v2. I also delivered the first Claude model release on AWS Trainium/Inferentia — partnering with James Bradbury (Anthropic's Head of Compute) and the Annapurna teams.

Explosive Business Growth

"SemiAnalysis believes Bedrock is a $5.5B run rate business today with the vast majority of customers (80-90%+) using Anthropic models."
— SemiAnalysis

There's a strange and wonderful feeling — after all the hard work — in watching a business you're responsible for, one of the company's core businesses, grow at breakneck speed. And with that growth, the pressure multiplies.

I also watched Anthropic itself grow up close — from a team of maybe fewer than 200 people to what it is today, its valuation climbing from roughly $18B in 2024 to $965B by mid-2026 — more than a 50× jump that made it the world's most valuable startup. When I told people at CVPR 2024 that I was working with the Claude model, I'd often get a blank look — they didn't know what it was. Today I'm pretty sure everyone knows and uses Claude, and Anthropic is a household name worldwide.

Senior Leadership, Up Close

This was also the first time I truly felt how much Amazon's most senior leadership cares about a business. We received tickets directly from the CEOs of customer companies. Every Sev-2 review pulled in at least two L10-level leaders — our VP and our Distinguished Engineer — and I worked directly with L8 Senior Principal Engineers. It was my first time collaborating that closely with leaders at that altitude. High visibility, high pressure.

Because the work was so early and so rare, very few people anywhere had real, hands-on experience with frontier-model inference. Anthropic wasn't yet a household name, and the company guarded the program tightly — for P&C and IP-protection reasons (on Anthropic's behalf), even other Bedrock teammates couldn't access our codebase or documents.

I also got the chance to know the folks at Anthropic I worked with day to day, and to build connections with others in the same domain. Over time, a number of those connections turned into genuine relationships — investors, founders, and researchers I now count as part of my network. Some of the most valuable parts of this chapter weren't in the codebase at all; they were the people the work put me next to.

Choosing to Step Sideways

After shipping my last task in Q1 2025, I knew I wanted to stop. Back from a vacation, I booked a meeting and sat down with the two Senior Principal Engineers to tell them I wanted to try a different direction. They were understanding, and offered me a few options.

At the time, Bedrock Inference was organized into three divisions: 3P (Claude and other closed-source models), 2P (open-weights models like Llama, DeepSeek, and Qwen), and 1P (Amazon's own Nova and Titan models). I moved from 3P to 2P, deep-diving the open-weights world and starting my research in model optimization (speculative decoding) and customization — the line I've been working on ever since. I would do literature reviews, paper readings, and research into advanced methodologies, and apply them on open-weights models. Around the same time I also moved my office from Seattle, WA to Bellevue, WA — a smaller, quieter town compared to the city.

Across these years I also led the benchmark methodology setup across two companies and through multiple rounds of new-model public releases. Through that work, I gained deep experience optimizing and benchmarking both open-weight models and closed-source foundation models.

Speculative Decoding and a Loop in the Timeline

I was lucky enough to be appointed co-chair of NeurIPS 2025 Mexico City — going from attendee (2019) to organizer (2025).

Another loop in this story-timeline is on speculative decoding itself. The first time I ever heard the concept of speculative decoding was at PyTorch Conference 2024 in San Francisco, in a talk by Xiaoxuan Liu. I had no idea, sitting in that audience, that a year later I would be working on this very domain deeply — that it would become the line of research I lead today.

Just two weeks ago, at MLSys 2026 in Bellevue, while browsing the posters, I came across an oral paper titled “ReSpec: Towards Optimizing Speculative Decoding in Reinforcement Learning Systems.” Because it was directly related to the speculative-decoding RL work I lead at the company, I was fascinated — I spoke with one of the authors on-site, Qiaoling Chen, to learn more about the paper. I was then surprised to find a very familiar name among the authors: Tianwei Zhang (Nanyang Technological University) — Qiaoling's advisor. Remember the Alexa AI Health & Wellness team I mentioned back in Chapter 2? Tianwei was my officemate there. This may be the most wonderful coincidence I've encountered yet. When you discover, at a conference, that the advisor of an author whose paper touches your own line of work was once your former officemate — especially after you've moved across so many different domains — everything you find suddenly feels reasonable and natural. I also met Xiaoxuan there — she received the MLSys Best Research Paper Honorable Mention for her new paper “Speculative Decoding: Performance or Illusion?”

---

Where I Am Now

A decade, five chapters, one compass. From Fintech to conversational AI, from containers to the foundation of the cloud, and now to the frontier of generative AI — every move traded comfort for a steeper learning curve, and every time, a curiosity I refused to abandon lit the way to the next door. The decision lens got sharper; the bet never changed.

---

Career Priority

If I compress a decade of these decisions into one picture, a few forces explain almost every move. They aren't a single ladder — they form a flywheel, plus two independent axes (role and domain), all riding on top of the technology cycles above. And in the AI era the ground under all of them is shifting, so it's worth asking what still holds value and what doesn't.

The unit of the whole thing: more leverage wins scope and impact, which earns visibility, rating, job security, and a higher level & role — and a bigger role hands you more leverage to spend. But notice the axle at the center: the wheel only turns on trust. Impact converts to visibility, and visibility to scope, only because people trust what you say and trust you with more — and unlike most skills, trust is transferable across domains and doesn't get commoditized by AI. The wheel turns on it. And what gets it spinning in the first place is your own drive — how much the work motivates you, and how productive you are once you're in it: trust is the axle, motivation and productivity are the torque.

One connected engine: technology cycles (x‑axis) decide which domain is hot, and a hotter domain sits higher — more leverage, opportunities, and possibilities. Inside every domain spins the flywheel above. You climb by jumping to the next hot domain, and those jumps are powered by transferable knowledge (fundamentals, systems thinking, taste, learning velocity) — while AI‑commoditized, domain‑locked skills (rote syntax, memorized APIs, single tools, gatekeeping titles) stay behind. At any rung, your role can move three independent ways: up a level, across a stance (IC ↔ Manager), or into a different job family (increasingly one “Builder / MTS” in the AI era).

The honest tension: optimizing purely for the flywheel keeps you safe but narrow; following interest across domains widens the map but resets the loop a little each time you jump. Changing domains carries a real cost and risk — and because everything is in motion, the tradeoff never sits still; striking that dynamic balance is an art of its own. My whole career has been a bet on the domain axis and the left column above — and, as the next note shows, the flywheel mostly caught up anyway.

---

A Note on Promotions — and Ratings

For anyone keeping score, neither promotion came on the first try:

• SDE I → SDE II — failed once in Q1 2017, then succeeded in Q2 2018 (AWS Payments).
• SDE II → SDE III — failed once in Q4 2021, then succeeded in Q1 2022 (AWS App Runner).

And here's the part I'd tell anyone earlier on: even with two promotions, I never once received an "Exceeds" or top-tier annual rating internally. At some point you realize the rating doesn't mean all that much — the work, and what you become doing it, does.

One more wrinkle worth recording: during my promotion cycle, the company hard-required a Tech Promotion Assessment (TPA) as a supplement to the package. The norm was one TPA for an L5→L6 promo, and two TPAs for an L6→L7 promo. A TPA is essentially an independent third party who interviews the peers and managers around you and runs a qualifying review of your work. The interesting part: the assessor is normally someone at the target level. In my case, the L6 engineer who ran my TPA was later promoted to Principal Engineer — so, by luck, I effectively got my work assessed through a PE's lens.

And the funny epilogue: shortly after my promo quarter, the company dropped the TPA requirement for L6 entirely — though it's still required for L7 promos. The complaint was that it cost too much time and too many resources — a TPA typically spent months collecting data and artifacts and writing up a comprehensive report. It simply didn't scale as the company grew fast and added more people.

---

On the IC vs. Manager Question

Over these years, in every team I stayed on, a leader offered or invited me to make the move from IC to manager — at least three times. I even operated as a people manager for a short stretch. And yet, by now, I've still chosen the IC role — for now.

Early on, I was deeply impressed by Carlos Arguelles (Senior Principal SDET at Amazon) and his blog “Belonging to Amazon's Principal Engineering Community”, and by Tanya Reilly's book “The Staff Engineer's Path.” I was lucky enough to connect with both Carlos and Tanya in person. For a long time, I loved the picture they painted of the IC path. And at Amazon, the number of Principal Engineers is far smaller than people managers at the same level — which made the senior-IC track feel both rarer and more compelling. So I turned down most of the offers to become a manager.

That said, I did take the internal I2M (IC-to-Manager) courses. They gave me a lot of perspective — perspective that's genuinely helped me operate as a senior IC across the company. I still keep an open mind about both the IC and manager paths.

And with the current wave of technical innovation, I'm watching organizational structures change dramatically. I don't have an answer about whether IC or manager is the better path right now — but I'll keep observing.

---

Farewell Notes

A small personal archive — the goodbye note I sent each team as I moved on.

Follow the curiosity. The career follows.