One of the key benefits of my tool is an algorithm that determines what and how much to order based on specific inputs. When we added perishable selection to the Store Order Tool (SOT), we hypothesized that this enhancement would reduce shrink caused by over-ordering. To validate this, I conducted an analysis by querying shrink transaction data for all stores from the prior year using SQL.

The analysis revealed the following insights:

1. Total Shrink Impact: Shrink across all sub-teams accounted for 5.5% of total revenue, equating to $1.1B annually, of which $778M is categorized as known shrink. Notably, 77% ($600M) of this known shrink originated from perimeter store selection, which was not yet utilizing SOT.

2. Key Shrink Causes: Of the $600M perimeter shrink, $400M was attributed to spoilage-related reasons: spoilage out-of-date, donation out-of-date, spoilage damage, and spoilage quality. This indicated a strong opportunity for technology solutions to reduce shrink caused by ordering inefficiencies.

3. Meat and Seafood Focus: Meat shrink totaled $108M, while Seafood shrink reached $62M. Even a 1% reduction in shrink for these two sub-teams would result in $1.2M in cost avoidance or savings.

This at the time helped justify the value of the features we intended to build and was further justified after the rollout of the technology. In 2024, we launched SOT to the Meat and Seafood sub-teams. While we are still collecting data, early results show a 5% decrease in shrink. If this trend continues, it would translate to an annual savings of $6M from reduced overbuying.

I led the development of Inbound Supply Chain features for Automated Buying and Receiving to support the Micro Fulfillment Center’s SVP goal. During the BRD review, stakeholders raised concerns about potential risks of over-ordering relative to available space, product temperature requirements, and FDA layer criteria. These risks necessitated the creation of a separate BRD and design process. After evaluating the implementation timeline, it became clear that the long-term capacity solutions would not be delivered until after the January 2025 ramp-up.

In addition to the timeline risk, there were uncertainties around post-code-completion testing time, whether the solution would perform as intended, and the fact that implementing systematic capacity guardrails within WFM processes was a first. To address these risks, I developed requirements for an interim, scrappy capacity guardrails solution. This contingency plan enabled the business to request capacity truncations at the ASIN level through SIM tickets submitted to engineering.

The configuration allowed the business to analyze:

1. Space allocation across Amazon Fresh, Core, and WFM

2. Prioritization of items critical to the program

3. Whether prioritized items would fit within the available ASRS space, ultimately calculating a maximum reorder quantity per ASIN

While the interim solution didn’t support all items like the long-term solution would, it enabled inventory replenishment to meet customer demand and supported the inventory ramp into the Automated Storage and Retrieval System (ASRS). My proactive approach—including the development of this contingency plan—helped mitigate risks from the delayed long-term solution and ensured the successful pilot and ramp-up of the new automated equipment. This foresight kept the project on track to meet critical milestones.

Yes—2024 was a year that required a lot of adaptability. I was responsible for driving communication and alignment across multiple stakeholders for new ordering features, and to support that, I delivered 16 detailed written program updates throughout the year. These updates became a go-to resource across Center Store, Perishables, Culinary, In-Stock, and Retail Ops. I also held bi-weekly meetings to review updates, gather feedback, and work through project trade-offs collaboratively.

The year presented several challenges: shifting priorities, reduced development capacity due to attrition, and scope increases that delayed timelines. One of the biggest pivots came when we unexpectedly lost six SDEs to attrition—just as the Micro Fulfillment Center (MFC) program began consuming more engineering capacity. This created a major delivery risk.

In response, I partnered closely with stakeholders to re-evaluate and realign priorities. I considered available headcount, assessed business value across competing initiatives, and modeled capacity plans to determine what could realistically be delivered. Based on those insights, I made trade-off recommendations and facilitated alignment on a revised roadmap that focused on the most critical goals.

This pivot helped minimize churn for the dev team, kept stakeholders informed and engaged, and allowed us to deliver as much value as possible despite the constraints. It also strengthened trust across the org and reinforced the importance of flexibility and clear communication in driving outcomes.

Background: In 2024, Amazon World Wide Grocery Stores Tech (WWGST) launched Amazon’s first automated grocery fulfillment operation know as a Micro Fulfillment Center (MFC) to reduce overall fulfillment costs. This Automated Storage and Retrieval System (ASRS) is designed to store and fulfill online orders for eligible Whole Foods Market (WFM) and Amazon Fresh items. The system is located in the back of a brick-and-mortar WFM store, enabling a goods-to-person fulfillment model where robotic devices bring items to associates, eliminating the need for manual picking and significantly reducing process walk time. The S-Team goal (highest goal type at Amazon) of this initiative was to improve variable cost per unit (VCPU) by ~3000 basis points, from $0.87 to $0.52.

This launch impacted multiple stakeholder groups, including customer experience (via Amazon and WFM e-commerce platforms), grocery automation (managing 3P robotic equipment integration), and the suite of ERP-like microservices under my ownership. These microservices span key supply chain domains such as receiving, inventory management, forecasting, reorder quantity calculations, and procure-to-pay (P2P) processes.

Problem: The Automated Storage and Retrieval System (ASRS) operates differently from traditional warehouse processes. In a traditional system, team members receive products, stock items, pick online orders, and manage replenishment manually. The ASRS, however, uses robots to manage these tasks automatically. After team members induct items into the system, robots handle stowing, picking, and replenishment operations before transferring products to team members for final packaging. Due to this automated process and unique storage method, we developed an automated replenishment system that triggers orders based on system data without human intervention.

Solution: Ryan defined requirements spanning over 15 systems and led the program across five engineering teams to design, implement, test, and launch the software in December 2024.  The components of the requirements are summarized below:

Eligibility Service

To identify items for automation, we built a user interface powered by DynamoDB and APIs to verify eligibility. Users log into the web UI to designate items for automated purchasing in ordering systems.

Ordering Inputs & ROQ Calculation

We implemented a mechanism to upload unique MFC-specific Target Inventory Positions and vendor schedules, accounting for distinct ordering days, delivery days, and vendor lead times. For eligible items, we ran a separate channel specific Re-Order Quantity calculation via backend Lambdas, using only online demand.

Capacity Guardrails

We built a direct integration with the 3P equipment to retrieve real-time capacity data, allocate capacity between Whole Foods and Fresh, and apply logic to truncate items after ROQ generation if they exceeded the machine's capacity.

PO Identifiers for Suppliers, Inventory, and Accounting Purposes

We created configurable identifiers that enabled MFC items to be placed on separate POs, included account # identifiers for suppliers to ingest via EDI-850 messages and treat this product differently in their fulfillment system to ship products on separate pallets and trucks, and ensured purchase orders were mapped to the correct cost accounts for P&L and balance sheet reporting. These identifiers were propagated through all downstream systems for receipt processing and integrated into existing reporting.

 Receiving Workflows

We introduced new receiving messages within the Store Receive Tool a mobile application on a Honeywell CT60 scanner to clearly indicate whether MFC products were part of a 3P or DC shipment, enabling team members to route them to back-of-house equipment instead of the sales floor.

Perpetual Inventory

Upon receipt, we established processes to track inventory events at key stages, including receiving, induction into equipment, sales, and spoilage for real time inventory tracking. Inventory was assigned to a distinct virtual bin to indicate whether it was designated for or already inside the equipment.

Results: We successfully deployed the equipment and automated supply chain components, enabling a select group of customers to order Fresh and Whole Foods products in a single checkout, all fulfilled via robotic automation. The rollout continues in 2025 as we scale to over 21,000 items being stored and automatically ordered through the system. Once fully implemented, the ASRS equipment will support $10M in online revenue while reducing fulfillment costs by 40%, generating $3.5M in annual savings.

Technical Challenges

The hardest technical part of launching the program was the capacity guardrails process. WFM buying systems did not have a concept of capacity incorporated in re-ordering calculations. For MFC, we defined requirements for controls for WFM and Amazon automated ordering systems to constrain ordering to what the automation hardware can physically hold, known as Capacity Guardrails. Capacity can be seen as three separate components 1) A component to provide visibility to what space is currently available within the machine 2) A component to split the machine capacity between WFM, Fresh, and Core space 3) a way to prioritize the order in which the item and its quantity is applied to available capacity and truncation of items that will not fit in the machine.

Component 1

The machine was organized in lanes of trays and each lane had three different dimensions.  The size of the lane width which varied in different 13 different sizes to fit all types of products, the temperature rating they could be stored in the lane ambient, chilled, or frozen product, and the FDA classification which was five separate categories of type of product such as raw meat or ready to eat.  We decided to name the combination of the 3 dimensions “bucket type”.  This resulted in over 200 bucket types.

Component 2

Once we knew the bucket type combinations and the quantity of lanes available per bucket type, we had to allocate the total buckets across Whole Foods, Fresh, and Core Product.  We decided to let the business decide two inputs which total our systems how to divvy this up.  One input was capacity %, this had to total to 100% and spread out across the three business units so that we wouldn’t consume into each other’s capacity to allow for the proper assortment of product.  Utilization factor was applied after the split and used to add a buffer if input from the machine we a little off to reduce the risk in over-ordering.  One key complexity in why we had to approach it this way is because ordering tools and backend services were different for Whole Foods and Fresh, in other words different tech stacks.  If we didn’t have different tech stacks we wouldn’t have had to split the capacity across business units, because we would be using one system. However, this was a technical limitation, so both systems had to know the capacity of the machine and use that in separate calculations and logic

Component 3

The final component of capacity guardrails involved using Whole Foods’ Lane allocation by bucket type to incrementally process items and their order quantities. Each item was assigned to a specific bucket type, with a maximum unit capacity per bucket. Additionally, we applied an item importance factor to prioritize higher-importance items before processing lower-priority ones.

As items were processed and buckets filled, any items that exceeded capacity were truncated and logged in a DynamoDB database to track unmet demand. Items that fit within the system were processed into a purchase order and transmitted to the supplier via EDI-850. The supplier then fulfilled the order, loaded the product onto a separate truck, and receiving tools facilitated the three-way match between the purchase order, receipt, and E-invoice. Upon receipt, the product was added to a back-of-house virtual bin, ensuring accurate tracking of equipment-specific inventory. Product was then brought to induct to be loaded in the equipment

Timeline Challenges
The Grocery Supply Chain (GSC) tech team was engaged late to support a 2024 launch. I wrote the Business Requirements Document (BRD) on April 19, just two weeks after being assigned the program. Our workback plan set a tech-ready date of October 25, allowing only five months for development and one month for testing and UAT, all while managing several other high-priority, in-flight features critical to the business. Given the number of systems involved and our existing headcount, I quickly recognized that we had two options: reduce scope and deprioritize certain requirements or request additional resources. Since resource allocation is often a lengthy process, I opted to proceed by cutting scope.

At a high level, the project required us to automatically generate reorder quantities, process purchase orders with unique identifiers, ensure proper receipt of products into the correct virtual bin, enable system-wide awareness of the MFC concept for transactional processing, and ensure no disruption to retail items or front-of-house store processes. To meet the October 25 deadline, we descoped the following:

• Capacity guardrails were postponed until ramp-up in January, as the gradual rollout allowed flexibility.

• Automation for Produce items was deprioritized since these items comprised only 15% of total machine-serviced volume.

• Low-volume edge cases (e.g., transformed items, DC pre-order items) were deprioritized, as they accounted for only 5% of total online retail items.

These changes were presented to key business stakeholders through a tradeoff document, which included VPs from Retail Operations, DC Operations, In-Stock, and E-Commerce—totaling approximately 50 stakeholders across five VPs. The document evaluated all potential options, ultimately recommending the descoping of the outlined requirements while treating them as fast follows. It also detailed other work that would need to be put on hold until the MFC implementation was completed. The business aligned with our recommendations and agreed to prioritize MFC over other planned 2024 roadmap initiatives. As a result, we met our tech-ready date of October 25, delivered capacity guardrails by the end of January, and are now working through the backlog for 2025.

Other challenges within this project were making all our supply chain systems aware of if the item was to go into the machine, input quality from catalog data authorities such as item vendor-mapping, and working though all the edge cases that could occurs.  If processes are fully automated, inputs need to be accurate so the right item, gets order from the right vendor, with the right quantity, as there is no human intervention.

Background: Supply shortages, manufacturing delays, and logistics challenges frequently cause product stockouts at distributors and Whole Foods Distribution Centers (DCs). When products are unavailable, substituting similar items helps meet customer needs. For example, while customers prefer fresh seafood, they often accept frozen alternatives when fresh options are unavailable.  In order to be able to substitute, a team member needs to know an item is out of stock and have awareness of an alternative that is in stock to service the demand of the customer.

Problem: The Store Ordering Tool (SOT) currently lacks visibility into out-of-stock items from both Whole Foods Market Distribution Centers (WFM DCs) and third-party vendors. When SOT creates a purchase order (PO) for WFM DC items, it routes through Direct Vendor Ordering (DVO) web for approval. While team members can modify orders based on DC communications about stockouts, DVO's system limitations prevent automatic notification of out-of-stock items or suggested substitutions. The current workaround of checking Order Link is inefficient and often leads to duplicate work.

DC stockout visibility and substitution capabilities are essential for scaling Variable Weight ordering, particularly given our current sourcing patterns from DCs: 72% of Meat, 17% of Seafood, 13% of Cheese, 11% of Accoutrements, and 10% of Commodity Cheese. Without these features, the system generates inaccurate Suggested Order Quantities (SOQs) for items requiring substitution, creating a false sense of order coverage. In reality, these orders often fail fulfillment due to upstream DC stockouts.

These system limitations trigger a cascade of operational challenges. The bullwhip effect disrupts the supply chain, while order writers face delays in proactively managing inventory positions to meet demand. The impact extends beyond operational inefficiencies - inaccurate SOQs increase the probability of stockouts, directly affecting sales revenue. Additionally, the system's limitations can lead to overordering as team members attempt to compensate for uncertainties, resulting in higher shrink rates. This is particularly problematic in perishable departments like meat and seafood, where products have short shelf lives and waste directly impacts profitability.

Solution: Ryan authored a product requirements document detailing a structured approach to addressing this problem, breaking it down into seven phases:

1. Ingest DC Out of Stock Data – Notify the order writer when a product is unavailable at the DC, allowing them to manually select a substitute.

2. Recommend Substitute Products – Provide constrained substitution options when an item is unavailable at the DC, while still allowing the order writer to make the final selection.

3. Optimize Reorder Quantity (ROQ) – Ensure accurate ROQ generation for substitute items.

4. Large-Scale Supplier Integration – Develop a mechanism for large suppliers to upload inventory levels and integrate this data into SOT ordering processes.

5. Local Supplier Integration – Establish a similar mechanism for smaller, local suppliers to upload inventory data and incorporate it into SOT ordering.

6. Substitution Behavior Learning – Analyze and learn substitution patterns for DC items to improve recommendations.

7. Advanced Substitution Optimization – Extend substitution logic to optimize for multiple variables, including in-stock rates, product cost, lead time, and selecting better-selling product varieties to maximize revenue.

Execution: In 2024, Ryan and his engineering team delivered three critical features to enhance the Store Order Tool's functionality. First, they implemented persistent inventory tracking that connects directly to the DC Warehouse Management System. Second, they developed data transformation capabilities to ensure compatibility between warehouse data and Store Order Tool requirements. Third, they created a new workflow enabling team members to flag out-of-stock items and select appropriate manual substitutions.

Results: The Solution launched in 2024 and scaled to the network in 2025.  The feedback from the team members were overwhelming positive and it’s anticipated that these features will impact in stock by 25 bps, estimated to deliver a $5M entitlement by the end of 2025.  The team has a backlog of items outline in the requirements for future incremental delivery.

Background: Amazon's retail fulfillment for customer orders has traditionally relied on a combination of third-party carriers, Amazon-owned assets (trucks and trailers with contracted drivers), and Amazon-owned assets with Amazon-employed drivers for LTL (Less Than Truckload) shipments. For small package deliveries, Amazon coordinates with various carriers including USPS, UPS, DHL, Amazon Logistics, and others. Due to high volumes, Amazon enjoys some of the best rates in the industry for these shipment modes.

However, for indirect procured assets or consumable expense items - such as lockers, furniture, signage, equipment, computer hardware, materials, Maintenance, Repair, and Operations (MRO) supplies, and other indirect products required to launch new buildings and sustain operations across the Amazon network - these goods are sourced through vendors who bill Amazon for the transportation costs. Annually, indirect transportation costs across Amazon's indirect supply base amount to $1.5 billion.

By leveraging Amazon's negotiated rates for indirectly procured items and their associated transportation, costs could be reduced by 51% for small parcel shipments, 15% for Less Than Truckload (LTL) shipments, and 15% for Full Truck Load (FTL) shipments. The estimated cost savings (entitlement) would be $100M-300M over a one-year period.

Problem: The program focused on reduction in freight costs however aimed to provide Amazon the visibility of freight shipment, enable controllership for freight payment, and improve operational readiness in a systematic and automated manner.

Solution: Ryan initially supported a make-or-buy decision analysis to either develop an in-house system or purchase a commodity product. However, due to other high-visibility and more valuable transportation automation projects, this initiative did not secure a place in the roadmaps of other middle mile technology teams. Consequently, the team decided to proceed with evaluating third-party SaaS Transportation Management Providers.

Ryan orchestrated a comprehensive RFP process across 11 SaaS providers, including Blue Yonder, Mercury Gate, Infor, Kuebix, and FreightPOP. These vendors were evaluated using a weighted scoring system that assessed user experience, product capability, technical specifications, and pricing. Following this evaluation, Blue Yonder emerged as the successful bidder and was awarded a $6M 3 year contract.

The team sought a SaaS provider that could deliver several critical features: a supplier-facing user interface for self-service pickup and delivery management, seamless integration capabilities with Amazon's indirect procure-to-pay software (Coupa), UPS API integration functionality, EDI capabilities for handling tenders (204), tracking signals (214), and invoicing (210). Additionally, the solution needed to provide an internal user interface for managing rate cards and carrier profiles, along with shipment optimization functionality based on cost effectiveness. These requirements were essential to streamline and automate the transportation management process while ensuring cost optimization across the network.

Execution: Ryan led the product requirements, program, and technical delivery of an TMS integration.  The integration team on the Amazon side was made up of five SDES and on the Blue Yonder side made up of a team of five including technical account managers, architects, and developers.

The SFI product is made up of six main systems:

Coupa – the indirect purchasing system in which POs are passed into the TMS

Freight Order Manager (TMS) – the supplier facing user interface (UI) which the supplier uses to enter in shipment inputs such as weight, freight, class, origin/destination, etc. to get shipments assigned to carriers, print shipping documentation such as the bill of lading, packing slip, and label, and track shipments after pickup

Transportation Manager (TMS) - the Amazon Facing UI responsible for rating, routing, planning, reporting, EDI transactions, and system configuration.  The brains of the TMS.

Controllership and payment systems – consisting of the EDI console to ingest invoices, TIPS which ingests and audits invoicing data to ensure Amazon is paying per contracted prices, Payee central/OFA for release of payment to the carrier after approval.

Accounting systems – Transportation Financial systems which will allocate transportation costs back to the owning cost center and assign transportation cost back to the asset allowing accounting the ability to capitalize transportation costs back into the value of the asset.

The SFI integration layer – the layer between all of the systems detailed below.  It is responsible for ingesting and passing PO data from Coupa to the TMS, updating shipping statuses in Coupa, providing manifest data in the required format to downstream systems, and handling consolidated reporting from all data sources.

The team worked to build the integration, improve the supplier facing user interface to meet Amazon’s needs, and get suppliers and carriers onboarded to the program. Ryan coordinated six supplier shippers, five domestic 3P carriers (UPS, T-Force, Yellow Freight, Roadrunner, and YRC), multiple internal cross-functional teams, and Blue Yonder's engineering architects. He oversaw the entire shipment lifecycle, from creation to internal accounting automation, ensuring operational efficiency and compliance. Ryan played a pivotal role in the Coupa to TMS integration, designing systematic controls to regulate data flows, implementing purchase order (PO) trigger logic, and ensuring that only relevant transactions were processed. By optimizing transactional processes, he successfully reduced shipment creation time for suppliers by 44% for Small Parcel (SP) and 28% for Less-Than-Truckload (LTL), driving a 77% increase in throughput.

To enhance user experience, Ryan introduced over 100 UI enhancements, including custom page configurations, advanced search filters, real-time alerts, bulk upload APIs, and reporting features. He also led the TMS to Coupa integration, enabling automated Advanced Shipment Notifications (ASN) to improve shipment tracking for the PO requestor. His strategic leadership and technical expertise ensured the successful deployment of the SFI system, driving cost savings, efficiency, and scalability across Amazon’s inbound transportation network.

Results: Within the first two months of launch, Ryan's leadership over the execution this VP level goal, resulted in $150K in savings, supporting deliveries to 200 destination sites across 29 different Amazon building types in 39 U.S. states, while achieving an impressive 99% delivery success rate.  During this process, Ryan built out a backlog of additional features and prioritized these features to scale the solution to more indirect suppliers

Background: Whole Foods Market (WFM) is implementing a Fresh Food Production (FFP) strategy to centralize food manufacturing, allowing in-store prepared foods (PFDS) to transition into finishing kitchens that require less space, equipment, and labor. This strategy includes two facility types: Micro-Kitchens (MKs), which produce a limited PFDS selection for fewer than five stores, and Metro-Facilities (MFs), which produce the full PFDS selection for an entire region.

Problem: To enable these facilities to produce food at scale, they needed a way to procure ingredient items directly from Whole Foods Market suppliers. However, the manufacturing facilities used Sage X3, a third-party Enterprise Resource Planning (ERP) system, to manage production, inventory, and supplier purchase orders, but there was no integration between the ERP and WFM systems. This gap created inefficiencies in procurement and supply chain operations.

Solution: To solve this, Ryan led the product requirements and technical delivery of an ERP integration, enabling manufacturing facilities to place orders directly with WFM Distribution Centers (DCs). The solution involved several key components. First, an API Gateway was implemented to manage authentication and access. Next, a Coral Lambda Endpoint was developed to facilitate RESTful API functions using CRUD operations, allowing the ERP to create, read, update, and delete purchase orders. A Processor Lambda was then built to enrich data by incorporating catalog and vendor foundational details before writing purchase orders to two Oracle databases—one for third-party orders and another for the WFM DC system. Additionally, a Simple Queue Service (SQS) was introduced to ensure FIFO (First In, First Out) processing, provide redundancy, and support high-throughput order volumes.

Execution: One of the major challenges in execution was foundational data inconsistencies. The ERP system relied on a weekly catalog file, meaning that any product code or department changes could cause API failures for certain purchase orders. To mitigate this, a Dead Letter Queue (DLQ) was implemented to log and redrive failed requests, and external tables were created to refresh ERP catalog inputs more frequently. A long-term solution was also proposed to externalize a service for real-time catalog updates.

Results: In 2024, Whole Foods Market successfully launched the first-ever Fresh Food Production proof of concept, and plans are in place to scale in 2025 to serve more Whole Foods locations. This integration is expected to reduce labor costs, improve operational efficiency, and increase operating profit by 5%, marking a significant step forward in modernizing WFM’s food production and supply chain capabilities.