AWSPrivate Pricing Program.

Why this work matters

AWS describes enterprise procurement as a mix of consumption models, commitments, custom pricing, negotiated terms, and predictable purchasing. Its public documentation makes clear that a private agreement is not just a price. It can include contract terms, configurations, payment schedules, renewals, and account-level controls.

The platforms supported 60K+ internal AWS sellers across Sales, Marketing, and Global Services (SMGS). At that scale, contract systems are revenue infrastructure. They have to preserve the intent of a negotiated agreement as it moves through documents, approvals, data, billing context, and reporting.

What was hard

The AWS Private Pricing Program supported more than $60 billion in enterprise commercial activity. The software had to make complex contract and analytics work easier to run while the program continued operating at that scale.

Contract work had grown across multiple systems and handoffs. Each system could perform its own function while the full journey remained difficult to see and expensive to change. Analytics had a related problem: useful customer and pipeline signals existed, but they were separated from the contract workflows where teams made decisions.

The job was not to add another interface. It was to reduce the places where context could be lost.

What I owned

I built and led an organization of more than 40 engineers and data scientists across enterprise contract management and customer analytics. I owned the connection between platform direction, team design, and delivery across both portfolios.

I treated the portfolios as one decision system. Contract activity could improve planning and customer intelligence; analytics could help teams make better contract decisions. The architecture and organization needed to reflect that loop.

I also built operating mechanisms around the work: clear portfolio ownership, weekly business reviews, operational-excellence reviews, principal-engineer leadership, and hiring standards that could hold as the organization grew.

What we built

We consolidated the contract experience around a clearer lifecycle instead of asking teams to assemble it across more than five enterprise systems. The platform connected contract processing, enterprise data integration, and the analytics needed to understand the customer and the program.

We also applied document intelligence and language models to contract processing. The useful question was not whether the technology looked impressive. It was where the system could remove repetitive reading and routing while preserving human review for consequential decisions.

The customer-intelligence portfolio created a centralized planning view that brought pipeline, customer, and forecasting signals together. The point was not another dashboard. It was a shared record that leaders and operating teams could use to make the same decision from the same facts.

What changed

Contract management and customer analytics became a clearer platform direction instead of isolated technology efforts. Contract activity improved the intelligence layer; the intelligence layer gave contract teams better context.

The organization changed with the systems. Principal engineers took on broader technical leadership, managers owned durable portfolios, and operating reviews connected delivery with reliability and business results.

What I learned

Enterprise platforms create value by preserving context across handoffs. Sophisticated technology does not make a large program simple on its own. Teams need agreement on the core workflows, the ownership around them, and what no longer needs to exist.

At this scale, platform leadership is as much about removing ambiguity as adding capability.