Amazon manages compensation for over 1 million L1–L3 hourly employees. A single $0.50 wage adjustment in the US translates to an $800M annualized investment and Amazon’s base wage investment grew from $0.8B in 2022 to $2.2B in 2024.

Yet the network wage review decision process was broken. Data existed across compensation, staffing, and operations systems but each team used different aggregations, different interpretations, and different tools. Forming a recommendation required weeks of manual data collection, spreadsheet modeling, alignment meetings, and repeat reviews. Ripple effects like wage compression were only discovered after decisions were already made.

Who I researched

I ran generative research with four distinct groups: VP-level Operations and PXT leaders who make final compensation decisions; Compensation Program leaders who prepare recommendations; Workforce Staffing analysts who own fill rate and attrition data; and Finance, who validate cost models before approval.

Critical findings

• The bottleneck was not data availability but synthesis — data existed, but nothing connected it into a single decision-ready view
• Leaders needed directional confidence, not precision — they wanted AI-guided recommendations they could challenge, not raw data
• Approval anxiety was high: the fear of making a wrong call at scale was paralyzing; risk signals needed to be surfaced proactively
• A single off-cycle wage review decision averaged 14 discrete handoffs across teams between data collection and approval and takes about 3 weeks to complete.

Three jobs-to-be-done

Following a design workshop with key stakeholders, I structured the entire design around three core tenets: Data Visibility (a unified real-time data view), Assisted Decision (AI-assisted scenario modeling), and Frictionless Approval (streamlined approvals). Each phase of the roadmap maps to one of these.

Unified data dashboard

The foundation was a consolidated interface surfacing base wages, shift differentials, premiums, incentives, KPIs, and market benchmarks together, integrated with the Labor Supply Model for real-time site-level data.

• Node-level and site-level views with clear drill-down paths, eliminating cross-dashboard context switching
• Fill rate, attrition, and tenure surfaced directly alongside compensation data
• RED/YELLOW/GREEN health indicators with user-configurable thresholds

AI-generated summaries

The most complex design challenge: surfacing dozens of interacting variables as natural language that VP-level operations leaders could act on immediately. I worked with data science to define the output format, tone rules, and edge cases.

• Spell out timeframes in full — summaries are read by operations VPs, not analysts
• Lead with the “so what” before the data: connect metrics to operational impact first
• Shift differential status is a required line in every health summary
• No weasel words — summaries must be precise and auditable

Scenario modeling

• Leaders compare multiple scenarios side-by-side with automated impact analysis
• Annotation layer for async collaboration — replacing email chains and meetings
• Compression and ripple effects surfaced upfront, not discovered after decisions
• One-click approval workflow replacing multi-meeting approval cycles

Amazon’s variable compensation — covering sales incentives and local allowances globally — was managed through PeopleSoft’s Variable Compensation Engine (VCE), built in 2009 and never designed for Amazon’s scale or international expansion.

PeopleSoft could only assign either a sales incentive plan or a local allowance to an employee — but not both. In countries where employees are legally entitled to multiple allowances (Mexico, Argentina, Uruguay), teams manually hardcoded workarounds that required monthly audits to maintain.

• 1,500 defects per year for sales employees receiving local allowances
• 35 comp consultants auditing 381 instances per quarter to correct errors
• 350–400 manual corrections annually from lack of job code standardization
• No built-in safeguards to validate plan assignments before deploying to large populations

Domain immersion

Before designing anything, I needed to understand a deeply technical domain: how variable compensation is structured legally and operationally across 26 countries. I embedded with Compensation Programs and the Sales Governance Working Group for several weeks.

• Stakeholder interviews across Compensation admins, Sales Operations, Pay Services, and HRBPs — mapping the full current-state workflow
• Reviewed COE (Correction of Error) reports and SIM tickets to understand the most common failure modes in PeopleSoft
• Studied local allowance requirements across 26 countries: tenure-based plans (Morocco), profit-sharing laws (Mexico), collective bargaining agreements
• Traced the full lifecycle of a variable compensation plan from creation through assignment, calculation, and correction

Critical insight

The fundamental problem was not UI polish but data modeling. The system needed to represent multiple variable compensation plans per employee with independent formulas — something PeopleSoft structurally couldn’t do. And comp admins needed confidence before committing changes. The fear of accidentally impacting thousands of employees was paralyzing — safety features were not optional, they were the core UX requirement.

Plan configuration UI

• Separate plan creation from plan assignment — reducing blast radius by requiring explicit confirmation at each stage
• One plan : one formula constraint — multiple eligibility groups per plan deferred to P3 to limit audit complexity and error cascades
• Inline eligibility builder: flexible criteria (location, org, job code, tenure, business entity, regulatory region) — configurable without engineering effort
• Calculation basis selector with system-level guards preventing recursive calculation errors

Simulation as mandatory gate

The simulation feature was the design centrepiece. Before any plan can be submitted for approval, the admin must view a simulation showing: employee count impacted broken down by manager/location/org, employees whose total compensation falls outside range, and a delta showing who is added or removed. This is a mandatory step — not optional — a deliberate choice to make the weight of large-scale decisions viscerally clear.

Approval & safety system

• Structured 2-step approval workflow: comp consultant initiates, principal comp consultant approves
• Approvers must be unique — no self-approval
• Rollback treated as an edit — same approval workflow, preserving full auditability
• Plan deactivation shows warning with active employee count before proceeding
• Error log with human-readable descriptions for every failed assignment — enabling self-service troubleshooting

Migration design

VCM had to migrate existing PeopleSoft plans before deprecating the legacy system. Many existing plans were incorrectly blended — Mexico’s aguinaldo bonus and vacation bonus combined as a single “additional pay” value. I designed the migration flow to disambiguate every blended plan by country, recalculate correct percentages, and reassign 43 discrete plans across 26 countries.

Every Amazon compensation event — annual review, promotion, transfer — depends on a set of configurable inputs: stock prices, exchange rates, haircut policies, formulas, and eligibility rules. In 2024, none of these inputs had a single administrative home.

• Stock price and exchange rate updates manually entered into PeopleSoft weekly/monthly
• Compensation formulas maintained in offline Excel calculators with no version control and no validation
• Event eligibility managed independently by each ACE product — no cross-product visibility
• Any input change required coordinated effort from product, engineering, program, and analytics teams — typically weeks to months

Four customer groups

• Compensation Programs team — primary administrative users; own the policy inputs and need to implement changes quickly
• ACE engineers and product teams — currently field all change requests and question escalations; want to be removed from the critical path
• Compensation consultants — need to understand existing rules to explain individual outcomes to employees and managers
• HRx employees — handle compensation administration queries; currently must ask engineering to look at code

Workflow mapping findings

• Control data required updates to multiple systems simultaneously — every update carried inconsistency risk
• Formula changes implemented in Excel had no version control, no validation against business rules, no history
• Eligibility changes required engineering to update backend code — average turnaround was weeks
• Rule exploration was entirely engineering-dependent: no self-service way to understand why a compensation outcome was calculated the way it was

Multi-tenant architecture

Control Center was designed as a multi-tenant platform — not a monolithic application. This meant VCM, and future GTMC teams, could build their own administrative modules within Control Center independently, without dependencies on the Control Data or Rule Configuration timelines. I designed the tenant integration pattern to ensure consistent visual language, permission models, and navigation across all modules.

Home page: ambient awareness

• Key data widgets: latest 30-day average stock price, current exchange rates, pending approval tasks
• Navigational tiles to each module — consistent entry point regardless of sub-product
• Ivy notification integration for proactive task alerts

Simulation as mandatory gate

No change can be submitted for approval without first reviewing a simulation showing: projected employee-level and aggregate cost impact, effective date of publication, and the approval threshold that will be triggered. The approval requirement is dynamically determined by the simulation outcome — not by a static SOP.

Rule transparency

One of the highest-impact features: translating compensation backend code into human-readable definitions. I designed a rule exploration interface that displays full formula breakdowns in plain language, shows event eligibility criteria in structured readable format, and links directly from A-to-Z and Manager Hub compensation experiences — so any manager can understand why an employee’s compensation was calculated the way it was, without needing engineering support.

Amazon’s shift differential (SD) system compensates for shift burden across all US Operations sites using a 14-category matrix based on Time of Shift (ToS) and Day of Week (DoW). Ensuring competitive and compliant SD rates is critical for fill rates and attrition — but the analysis process was entirely manual.

Each of the ~72 annual SD review requests involved 3–5 people and several hours of manual analysis: pulling data from HAC, G&C, and OCEANS, building spreadsheets, identifying priority sites, and preparing recommendations for leadership. There was no standard methodology, no self-service capability, and no way for business leaders to explore site-level SD health without waiting days or weeks for a compensation analyst.

• Data scattered across 3+ systems with no unified view
• No standardized methodology — analysis varied analyst to analyst
• L8+ Operations and PXT leaders had no ability to self-serve site-level insights
• No visibility into which sites to prioritize without manual intervention

Two primary user groups

Business Leaders (L8+ Operations and PXT): Make investment decisions about shift differentials. Their needs: understand which sites require intervention, see historical context and previous decisions, compare sites quickly, and get fast turnaround for decision-making. Their pain: long wait times for analysis, no independent access to site-level details.

Compensation Leaders: Evaluate SD review requests and prepare recommendations. Their needs: AI-generated insights in under 30 minutes, standardized methodology across reviews, comparison to node standards. Their pain: manual data gathering from multiple systems, spreadsheet-based analysis prone to errors, days or weeks to complete a single analysis.

Domain research

I studied the SD Burden Matrix framework deeply: 14 finite categories, burden hierarchy rules (Deep Night > Night > Swing > Day; Weekend > Weekday), the distinction between Rules (SD matches site matrix standard) and Exceptions (approved deviations), and the site priority classification system (P1 through Standard) driven by fill rate and attrition thresholds.

AI-generated summaries with SD context

I designed the AI summary system to weave shift differential status directly into the compensation health narrative — not as a separate section, but integrated with fill/attrition analysis.

• Health status line always includes SD status (Below/At/Above Node Standard)
• Segmentation analysis calls out SD gaps by matrix category
• Material changes section connects SD status to observed attrition trends
• No weasel words; one decimal place for percentages; two decimal places for rates

Heat maps and site visualization

• Site-level heat map: sites colored by SD status relative to node standard (Below/Match/Above)
• Rate comparison heat map: color intensity based on SD rate by matrix category across adjacent nodes
• Hover tooltips showing exact rate, category, and % match to node standard
• Multi-select filters: site type, priority level (P1/P2/P3), matrix category, launch date range

Detailed matrix category drill-down

• Expand any matrix category to see all cohorts within it
• Rule (R) / Exception (E) indicator for each cohort — green R for rules, red E for exceptions
• Exception direction (above/below standard) shown alongside actual SD values for comparison
• Color-coded risk indicators: Red (fill <90% AND attrition >2%), Yellow (either threshold missed), Green (both met)