In 2023, I was asked to lead the solution architect and program management effort for the Amazon Aurora Limitless launch at AWS re:Invent. At the time, I did not fully appreciate the scope of what that meant. Aurora Limitless was not just another product release. It was one of four S-Team goals for all of Amazon that year — meaning it sat alongside a handful of other priorities that Amazon's most senior executive leadership reviewed directly. Four goals, across an organization of over a million people.
I led a cross-functional global team of 80+ engineers, solutions architects, quality engineers, and technical program managers across multiple time zones. My scope included UX design review, end-to-end quality automation, building the pre-launch test framework, and running execution reviews with AWS senior VPs to secure resources and leadership alignment. We launched at AWS re:Invent 2023 in Las Vegas.
Here is what that experience taught me.
Executive Alignment Is a Technical Skill
The most technically complex part of the Aurora Limitless launch was not the distributed SQL engine itself. It was keeping 80+ people rowing in the same direction while the product was still changing under them.
At Amazon, the mechanism for this is the weekly business review. I ran execution reviews with AWS senior VPs, including VP of Database Services Rahul Pathak. The purpose of those reviews was not to report status. It was to surface blockers, negotiate priorities, and secure the resources the team needed to hit the launch date.
To do that effectively, you need to translate deeply technical blockers into business language — not because leadership cannot understand the technical details, but because the decision being made is a business decision. "We need two more weeks on the distributed transaction coordinator" means nothing in a VP review. "The current query consistency model creates a customer-facing correctness risk that we can mitigate in two weeks or accept as a known limitation at launch" is the same information packaged for the actual decision.
The ability to translate technical risk into business decision is what separates program managers who execute from those who merely report. I had to develop this skill under pressure, in front of senior VPs, on a high-visibility product. It accelerated my thinking about how engineering and business actually connect.
Quality Automation Cannot Be an Afterthought
One of my responsibilities was partnering with the quality engineering team to build the pre-launch test framework for Aurora Limitless. This was not optional — at the scale and visibility of an S-Team goal, manual QA is not a viable approach. The test framework needed to be automated, repeatable, and integrated into the release pipeline before we were anywhere near launch.
The instinct on high-pressure launches is to trade quality for speed. Get it out the door, patch it afterward. That instinct is wrong, and it is especially wrong for database infrastructure. A correctness bug in a distributed SQL engine does not surface as a bad user experience. It surfaces as data loss or inconsistency at a customer's most critical workloads. The reputational and contractual cost is enormous.
What we built was a framework that tested distributed query correctness, consistency under concurrent writes, and failure recovery scenarios — automatically, as part of every build. The discipline required to build that framework under launch pressure was significant. But it was the right call.
Program Management at Scale Requires Systems, Not Heroics
Managing 80+ people across time zones is not something you can hold in your head. Early in the program, I tried. I had working memory of every open blocker, every team dependency, every in-flight decision. That worked for about three weeks. Then the program grew, the complexity compounded, and I needed a different approach.
What replaced the heroics was structure: a single source of truth for dependencies, a clear weekly cadence for surfacing blockers, and a ruthless prioritization of what actually needed my attention versus what teams could resolve autonomously. The best program managers I observed at Amazon were not the ones who knew everything. They were the ones who built systems that made the critical information visible automatically.
UX Is a Product Decision, Not a Polish Step
I also owned the UX design review for Aurora Limitless. For a database product, UX might seem like an afterthought — the customer is connecting via a JDBC driver, not clicking buttons. But the "UX" of a database product is its operational experience: how a cluster looks in the console, how you monitor shards, how you interpret an explain plan for a distributed query, how you diagnose a hot partition.
Getting those surfaces right required treating them as product decisions, not polish. We reviewed console flows the same way we reviewed the distributed consistency model. The customers who adopt a product first are the most technically demanding. Getting the operational experience wrong for them creates a reputation that is hard to reverse.
What Launching on the World's Biggest Stage Feels Like
re:Invent is attended by tens of thousands of people. The launch announcement was in a keynote. The moment the product was announced, customers started asking about it. That is a very different pressure than a standard GA release.
What I remember most clearly is the week before launch: the late reviews, the last-minute blockers that felt insurmountable at 11 PM and turned out to be solvable by 9 AM, the specific feeling of knowing that something you helped build was about to be in front of the entire cloud industry.
Aurora Limitless launched on schedule. It was one of the most demanding professional experiences I have had, and also one of the most formative. The lessons from it have shaped how I approach every large-scale program since.