Ocado Technology treats machine learning as part of an end-to-end grocery platform, with use cases covering search, recommendations, routing, warehouse automation, and workforce support.
2
Gabriel Straub argues that data platforms must account for different needs among data producers and data consumers, while giving teams enough autonomy to move quickly.
3
Machine learning work should be judged by customer and business outcomes, such as reducing food waste, rather than by the sophistication of the model.
Summary
Gabriel Straub describes how Ocado Technology built its own technology for online grocery because existing systems did not fit the business. The company now develops a platform for retail partners, with machine learning used for search, recommendations, routing, demand forecasting, warehouse robotics, and other operations. The central challenge in his role is scaling this work across very different applications. He argues that there will be several golden paths rather than one standard ML stack, because batch recommendation systems, optimization algorithms, and low-latency vision systems have different needs. He also discusses the tension between data producers and consumers. Most employees produce data, but they may not understand how a change affects downstream teams. Ocado is exploring governance based on data utility and feedback rather than heavy access controls. Gabriel is candid that this problem is unresolved. He also explains why teams should start with simple rules and use customer outcomes to decide whether ML adds value.
Ocado built its own grocery technology because the existing market could not handle the problem
Gabriel explains that Ocado started around 20 years ago as an online grocery business. Grocery required large baskets, different temperature regimes, short shelf life, and efficient delivery despite thin margins. The available technology did not solve these problems well, so Ocado built much of its own software, automation, and robotics. About seven years before the interview, the company began selling this technology platform to other retailers. Gabriel says Ocado Technology now has 11 clients across the world and about 2,500 people in technology teams working across robotics, AI, software engineering, and UX.
Ocado uses ML across customer experience, optimization, automation, and staffing
Gabriel groups Ocado's use cases into several areas. Search and recommendation systems help customers find products among roughly 50,000 items. Optimization supports vehicle routing and warehouse operations. Robots move across warehouse grids, while vision systems help robotic arms identify and pick products. Ocado also studies where automation can help partners scale their operations when hiring drivers and fulfillment-center workers is difficult. These systems are developed with retail partners and then rolled out across the platform.
Edge inference is useful when vision systems have tight latency and bandwidth constraints
For robotic picking, cameras stream video and the system must identify a precise location for the arm to grasp an item. Gabriel says Ocado uses localized computing, including a localized GPU, because latency and bandwidth matter. Training can still happen offline, while inference runs closer to the equipment. This is one example of why the platform cannot use the same architecture for every ML application.
Scaling ML requires choosing where to create cohesion and where to preserve autonomy
Gabriel's remit covers data science, analytics, governance, and engineering. He is trying to make data and ML central to the organization without assuming there is one operating model. Ocado works across multiple application types, so it needs shared structures, platforms, and processes alongside local variation. He describes four broad patterns, including classical ML with offline training and batch serving, optimization systems that rely more on simulation and Java, and vision systems with different latency requirements. Some patterns have a mature golden path, while others still need experimentation.
A golden path should improve reproducibility and safety as well as delivery speed
Gabriel says a well-designed path can reduce time to value and time to iteration, but it also supports reproducibility and security. He expects production systems to use familiar software engineering practices such as CI/CD and continuous testing. Model drift and data drift extend ideas that already exist in software engineering. He also points to data quality, accessibility, lineage, and governance. Different ML applications need different paths, especially when the feedback loop is less clear or the work involves non-tabular data.
Data producers need feedback about downstream effects without being trapped by heavy governance
Most of Ocado Tech's 2,500 employees are software engineers, so the organization has far more data producers than data consumers. Producers may know their own area well without seeing the full platform. A change can alter the meaning of data without breaking a pipeline, which can still damage another team's ML system. Gabriel says governance should focus less on access control and more on data utility, combining quality, accessibility, and other measures. He is also considering how data engineering can enable software engineers instead of becoming a bottleneck. The right balance between central control and local freedom depends on risk and organizational maturity.
Customer outcomes matter more than model sophistication
Gabriel uses demand forecasting to explain how technical work should connect to business value. Ocado may use an exciting neural network, but the more useful measure is purge, the amount of product thrown away because it was not sold. He says Ocado's purge rate is about 0.4%, compared with an industry average of about 2%, and that the measure connects to money and food waste. Customers do not wake up wanting a smarter application. They want an experience that is simple and effortless. ML is an input to value, not the outcome.
Simple rules should provide a baseline before a team introduces ML
Gabriel takes a middle position on advice to avoid ML when rules would work. Teams should start simply, often with a rule-based system, while designing the architecture so that the rules can later be replaced by an ML component. A basic heuristic also provides a baseline for measuring whether ML adds value. This approach avoids adopting ML for its own sake while preserving a path to more complex methods when the business needs them.
Adoption improves when teams sell the benefit to the person using the system
Gabriel describes an early pricing-optimization rollout that focused too much on the system's intelligence. The team talked about competitor prices, price elasticities, and product relationships, which made the business unit feel that the machine was claiming to be smarter than its experienced staff. A later rollout focused on reducing manual work and keeping prices up to date. That message worked better because it addressed the individual's daily problem as well as the company's goal. Gabriel connects this to a wider cultural issue: automation is easier to accept when it removes tedious work and leaves people more time for valuable tasks.
