Stephen Batifol treats internal developer advocacy as part of the ML platform, with documentation, onboarding, tutorials, and user support.
2
Wolt's platform uses open-source tools to let data scientists train and deploy models without managing Kubernetes details or writing repeated infrastructure code.
3
A user community helps the platform team collect feedback, share examples, and avoid becoming a permanent support bottleneck.
Summary
Stephen Batifol describes how Wolt built an internal ML platform and how his role moved from platform engineering into internal developer advocacy. The platform runs on Kubernetes and uses open-source components for workflow execution, experiment tracking, and model deployment. Its purpose is to reduce the infrastructure work data scientists face, such as handling resources, deployment patterns, monitoring, and repeated model training across countries or cities. Stephen says adoption depends on the user experience rather than the underlying technology. He focuses on documentation, getting-started guides, tutorials, simple explanations, and regular contact with data scientists. Wolt also uses Slack discussions and meetings every two weeks to share examples and gather feedback. Stephen is candid about the tradeoffs of Kubernetes, including resource allocation, data placement, logs, and hiding annotations. He also discusses LLM support, GPU capacity, latency, and possible internal support use cases. Public talks and meetups have helped Wolt hire platform engineers through inbound interest.
Stephen moved from building the platform to helping people use it
After almost three years on Wolt's ML platform team, Stephen became frustrated by the amount of YAML and by platforms that try to handle everything. He proposed an internal developer relations role because Wolt had created its own ML platform. The platform does not force teams to use it, so he has to explain why it makes their work easier. His work includes documentation, getting-started material, tutorials, and conversations with users. He also rejects the idea that developer relations mainly means attending conferences. For Stephen, much of the job is making the platform simple and helping data scientists get productive without learning every underlying system.
The platform uses open-source tools to hide repeated ML infrastructure work
Stephen says Wolt's ML platform is built with open-source tools because Wolt believes in open source and contributes to it. The data platform includes Snowflake and Airflow, while the ML workflow layer uses Flyte. MLflow sits in the middle for experiment tracking. Model deployment uses Seldon, which can create microservices and endpoints, add metrics, and support shadow deployments and A/B testing. Stephen likes that a data scientist can define a model and its training library while the platform handles much of the surrounding work. The user does not have to write the same monitoring, streaming, or deployment code repeatedly.
Flyte makes repeated training across countries or cities easier
When Demetrios asks about the platform's selling points, Stephen starts with the user's task rather than the technology stack. A data scientist might need to train a model for 25 countries or for many cities. With Flyte, they can add a decorator and define a dynamic workflow that loops through a list and trains the models. Stephen contrasts this with manually training models one by one or writing Spark code to parallelize the work. The platform also provides access to GPUs through autoscaling. GPUs scale down when unused and return when needed, although Stephen says Wolt is not training very large models for weeks at a time.
Kubernetes is useful only when its operational details stay out of the user's way
Stephen wanted the platform to run on Kubernetes, but he describes several hard parts. If data scientists should not need to know about pods, deployments, kinds, labels, or annotations, the platform must hide those details while still exposing logs and the resources users need. The team also has to decide how projects share memory and GPUs, and where data should live. Wolt avoids putting data workloads directly on Kubernetes by using Flyte to read from and write back to Snowflake. Stephen also recommends K9s, a terminal tool that gives users a visual view of the cluster and lets them inspect resources and logs without memorizing Kubernetes commands.
Model serving is treated like ordinary software after deployment
Stephen says deployed ML models follow a normal software on-call rotation. Training failures can wait for a few days, but deployed models need operational monitoring. The team checks whether the deployment is healthy and whether an issue comes from Kafka, a database, or another dependency. He does not want model serving to receive a separate operational treatment simply because it involves machine learning. The ML platform has its own service-level objectives for availability, while model incidents are handled through the regular software process. Wolt also uses a rotating squad made up of people from different teams, including data operations and machine learning platform work, rather than a separate permanent SRE team.
A user community keeps the platform team from becoming a bottleneck
Stephen gets feedback through Slack and meetings with data scientists every two weeks. Users report that documentation is outdated or ask whether a task is possible on the platform. He wants users to share examples with each other, such as training models across countries or using GPUs, so the platform team is not always the only source of answers. He deliberately tries not to answer every Slack question immediately because constant intervention can make users dependent on the platform team. He also invites users to create pull requests with him. That lets them improve the platform directly and changes their relationship with the team from support consumers to contributors.
Public advocacy helps Wolt attract platform engineers
Stephen says the last three or four people hired onto the platform team came inbound after seeing his talks, videos, or blog posts. The team grew from three people to seven. One candidate first contacted him after an early KubeCon talk, when Wolt was not hiring, and applied a year later when positions opened. Stephen tries to write and speak in a direct, approachable tone instead of presenting the platform as a personal achievement. Hosting MLOps Community meetups at Wolt also gives engineers a chance to visit the office and talk with the team. He says the public work helps people understand both the technical problems and the idea of making data scientists' work easier.
