A developer deploys a service in five minutes. The platform team celebrates another adoption win. Three weeks later, the service degrades in production. The SRE on call has no idea who owns it, what healthy looks like, or why the alerts aren't useful. The platform worked. The deployment succeeded. The SRE is still doing archaeology instead of debugging. Developer platforms reduce friction for developers — golden paths, self-service workflows, automated deployments. All stop at deployment. Ownership, SLOs, meaningful alert thresholds — none are required outputs. So they don't exist when someone needs them most. With AI-assisted development, this gap is getting worse. More services ship faster, with less tribal knowledge baked in. The developer who wrote it may not fully understand it. The SRE inheriting it definitely doesn't. The fix isn't better tooling or more runbooks. It starts at the platform — treating operational context as a required output of every deployment, not an optional annotation added later. Attendees leave with a concrete view of what that looks like, and a starting point for closing the gap between developer experience and operator experience in their own platform.
Known across the cloud-native community as Maharaj, I make complex technology accessible - from KubeCon stages to community meetups to client boardrooms. What started as a manual QA engineering career over a decade ago has evolved into leading developer relations at scale as a Principal Developer Advocate. I combine engineering depth with narrative instinct - debugging a Kubernetes operator in the morning and crafting a developer content strategy by afternoon.
