0.5 dodroxrox26 2026-09-22 2026-09-23 2 00:05 https://talks.devopsdays.org US/Mountain Main Stage Other 2026-09-22T08:00:00-06:00 08:00 01:00 Menu to come. Please let us know if you have any dietary restrictions when registering. dodroxrox26-6731-registration-sponsors-breakfast-day-1 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/P9SJNM/ https://talks.devopsdays.org/dodroxrox26/talk/P9SJNM/feedback/ Main Stage Keynote 2026-09-22T09:15:00-06:00 09:15 01:00 When something breaks in production, nobody calls 911; you and your team _are_ the emergency responders. The fire service has spent more than a century learning how to organize people under pressure, and much of the tech industry has quietly adapted those lessons, often without realizing where they came from. But the fire department only covers half the job. Fire marshals cover everything outside the fire itself: preventing fires before they start, and investigating them afterward to figure out what really happened and what should change. In this talk, we'll look at what DevOps and SRE teams can learn from both the fire department and the fire marshal: how the Incident Command System translates to managing technical incidents, and how the investigative mindset of the fire marshal can transform your incident reviews from blame-and-forget rituals into the most valuable learning your organization does. Expect practical lessons, a few war stories, and some surprising parallels between fighting fires and keeping services running. dodroxrox26-6545-when-production-burns-you-re-the-fire-department-and-the-fire-marshal-too Talks Brent Chapman en Whether you're new to on-call or you've been running incidents for years, you'll leave with practical insights about responding to incidents, preventing them, and learning more from the ones that happen anyway, despite your best efforts. false https://talks.devopsdays.org/dodroxrox26/talk/HA9EMA/ https://talks.devopsdays.org/dodroxrox26/talk/HA9EMA/feedback/ Main Stage Break 2026-09-22T10:15:00-06:00 10:15 00:45 Coffee and other non-alcoholic drinks included all day. Snack list coming later. dodroxrox26-6550-coffee-break-day-1 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/XQVQKM/ https://talks.devopsdays.org/dodroxrox26/talk/XQVQKM/feedback/ Main Stage Talk 2026-09-22T11:00:00-06:00 11:00 00:30 Most teams will tell you they have SLOs. **Most of them are doomed to fail.** Not because their metrics are bad or their tooling is wrong, but because reliability has no seat at the table. **SLOs are useless unless they inform your roadmap.** If error budget exhaustion doesn't change what gets built next sprint, you don't have an SLO program. You have an expensive monitoring system. This talk draws on firsthand experience leading SRE initiatives and tech consulting to name the organizational patterns that make SLO programs fail, regardless of how much effort teams put in. You'll leave with a five-question diagnostic you can run at your next retro to find out exactly where your organization stands, and a clear picture of what it actually takes to give reliability the authority to change behavior. dodroxrox26-6201-why-most-slos-fail Talks Amin Astaneh en This talk is drawn from direct SRE leadership and consulting work experience assessing SLO programs across engineering organizations of varying size and maturity. The failure modes described are ones I've observed repeatedly in the field- in organizations that had done everything "right" on paper and still saw no material improvement in production reliability. **Why this talk:** Most SLO content focuses on the technical implementation- how to define SLIs, calculate error budgets, and build dashboards. **That's not the problem.** Teams that have done all of that are still failing. **The gap is organizational, not technical, and it's rarely discussed.** Outline: * Why SLO programs fail even when teams do everything right * Four antipatterns observed firsthand that guarantee failure, regardless of tooling or effort * A maturity model for SLO programs- and why the jump from immature to minimal maturity isn't technical * What it practically takes to give reliability a seat at the table: exec commitment, enforced error budget policy, and product in the room * A five-question diagnostic practitioners can run **immediately** to assess where their organization stands **Audience takeaways:** * The reason most SLO programs fail isn't technical- reliability lacks organizational authority, and no dashboard fixes that * A concrete maturity model to locate where your organization actually is, not where you think it is * Five diagnostic questions to run at your next retro that will tell you everything about your SLO program's health Speaker background: ~20 years in tech, ~10 in DevOps/SRE. Seasoned public speaker. false https://talks.devopsdays.org/dodroxrox26/talk/FDTEUK/ https://talks.devopsdays.org/dodroxrox26/talk/FDTEUK/feedback/ Main Stage Ignite 2026-09-22T11:30:00-06:00 11:30 00:05 Most DevOps teams are quietly running the same experiment right now: how much can we let AI agents do without us? Generate code, run scripts, deploy infrastructure, open PRs — the trust window keeps widening. Coding agents have earned some of it. Benchmarks like MMLU have been flat since 2024 — what improved is execution: tool use, multi-step planning, persistence. That's what "agentic" means. So I gave agents access to real infrastructure — cloud accounts, Kubernetes clusters, Git repos — with no human approval, just execution. Some results were genuinely useful. Others destroyed days of work, created infinite loops on shared clusters, and crossed boundaries I didn't know existed. This talk shares five war stories from those experiments: - **The Context Gap:** An agent lost its context mid-deploy and started making raw AWS CLI calls on a shared account - **The Git Disaster:** Asked to clean up a secret, the agent wiped an entire repository — confidently, irreversibly - **The Infinite Loop:** An agent and a GitOps controller entered an endless fix-revert cycle that neither would stop - **The Invisible Blast Radius:** A schema fix that worked perfectly in dev silently broke production - **The Hit Piece:** An agent told to write about open source instead wrote a personal attack on a maintainer Each story started somewhere safe and drifted somewhere dangerous — without the agent ever announcing the transition. I'll introduce a **Reversibility x Blast Radius framework** that maps where agents are safe, where they need supervision, and where they shouldn't operate alone. You'll leave with concrete safeguards (dry-run diffing, scoped credentials, protected branches, read-only patterns) and an honest look at the cases where no guardrail exists yet. dodroxrox26-6087-when-ai-agents-touch-real-infrastructure-five-war-stories-and-a-frameworkk Ignite Talks Adam Gordon Bell en false https://talks.devopsdays.org/dodroxrox26/talk/ZEQ839/ https://talks.devopsdays.org/dodroxrox26/talk/ZEQ839/feedback/ Main Stage Ignite 2026-09-22T11:35:00-06:00 11:35 00:05 “Question everything.” It’s not a new idea — Socrates lived by it centuries ago. We are living in an age where there is an abundance of knowledge and individuals comfortable with accepting things as face value. But, should we and how can we look deeper with what we are being told is “secure” in our world of “security”? Where’s the line between trust and curiosity? In security, blind trust is dangerous. Open source code powers everything from your phone to federal systems. Yet almost no one stops to ask “Who is writing this code?” That one question can reveal risks that scanners and reports will never show you. This lightning talk is a call to think critically, challenge assumptions, and strengthen our collective defense by asking the questions others overlook. Together, we’ll explore how curiosity fuels innovation, why trust without verification creates risk, and how a simple question can shape the future of security. dodroxrox26-6192-question-everything-how-curiosity-strengthens-security Ignite Talks Amanda Aguayo en Lighting Talk: 20 Slides - 15 seconds each Slides 1-3 - Walk through “Question Everything” concept by Socrates Slides 4-8 - Real world examples of the impact of people asking simple questions which demonstrate global change. Slides 9-13 - What security questions are we not asking? Provide examples. Slides 14-18 - What the impact can be in asking the question that I am most interested in: Who is building the code within your software supply chain? Slide 19-20 - Encourage the audience to ask themselves simple and important questions. false https://talks.devopsdays.org/dodroxrox26/talk/UKQQRK/ https://talks.devopsdays.org/dodroxrox26/talk/UKQQRK/feedback/ Main Stage Ignite 2026-09-22T11:40:00-06:00 11:40 00:05 Modern software failures rarely begin with a dramatic outage. More often, they begin with ambiguity: unclear requirements, misunderstood intent, assumptions hidden inside AI-generated code, or systems nobody fully understands anymore. This Ignite talk explores how tiny moments of unclear communication compound into operational complexity, architectural drift, technical debt, reliability problems, and human burnout. Through a rapid, cascading narrative inspired by the classic “for want of a nail” structure, this session connects language, software architecture, DevOps, AI-assisted development, and operational reality into a single systems story. Because sometimes the difference between resilient systems and fragile ones begins with something surprisingly small: a clearly written sentence. dodroxrox26-6204-for-want-of-a-clearly-written-sentence Ignite Talks Matt "Kelly" Williams en false https://talks.devopsdays.org/dodroxrox26/talk/VAQDC3/ https://talks.devopsdays.org/dodroxrox26/talk/VAQDC3/feedback/ Main Stage Ignite 2026-09-22T11:45:00-06:00 11:45 00:05 I've built banking pipelines for 10 years. My company just told me we're deploying AI agents. I started researching what changes — and found 5 things my pipeline has no answer for: 1. "Build passed" — but the model wasn't tested against this week's data 2. "Health check passed" — but "up" doesn't mean "correct" for AI 3. "Deployment successful" — but which version: the code, the model, or the context? 4. "Cost normal" — but token costs don't appear in your cloud bill like compute does 5. "No alerts" — but the AI failed silently because nobody defined what "wrong" looks like 5 failure modes that your current pipeline has no answer for. 5 slides each. 5 minutes. Drawn from production failures documented in public post-mortems and infrastructure gap analysis from 10 years of banking deployments. dodroxrox26-6323-your-ci-cd-pipeline-is-about-to-meet-ai-here-s-what-it-doesn-t-know Ignite Talks /media/dodroxrox26/submissions/Z8DCQ8/image_bRPEkGW.webp Saideep Navakoti en A fast, opinionated 5-minute format: one failure mode per minute, drawn from documented production post-mortems and infrastructure gap analysis. The structure maps cleanly to the Ignite format — 4 slides per failure mode (the assumption, why it breaks for AI, what it costs, and the right question to ask instead). No tools, no demos — just the 5 mental model shifts every DevOps engineer needs before their first AI deployment. Designed to spark open space conversations rather than close them. false https://talks.devopsdays.org/dodroxrox26/talk/Z8DCQ8/ https://talks.devopsdays.org/dodroxrox26/talk/Z8DCQ8/feedback/ Main Stage Ignite 2026-09-22T11:50:00-06:00 11:50 00:05 My father-in-law buys salvage cars, fixes them up, and sells them with real pride in the work, but the family cars always have a check engine light on. It's not that he doesn't care; he knows he can fix anything that breaks, so the urgency never lands. Many engineering teams treat their internal tools the same way. These teams ship to their customers with pipelines, versioning, and signed releases, but ship to themselves through PATH hacks, Slack threads of curl | bash, SSH access to a specific box that builds the binary nobody else can rebuild, and S3 buckets of artifacts that nobody owns after the engineer who wrote the original leaves. The xz utils backdoor and the recent VS Code extension compromise that breached GitHub itself should have shifted the calculus, but the patterns persist anyway because the engineering equivalent of a check engine light still feels tolerable. The talk walks these patterns using firsthand examples from a few teams and language ecosystems I've worked in, and digs into what makes them so persistent. The audience walks away with vocabulary for the patterns and a sharper read on why engineering orgs keep tolerating them. dodroxrox26-6367-salvage-title-software-how-engineering-teams-ship-to-themselves Ignite Talks Morgan Helton en false https://talks.devopsdays.org/dodroxrox26/talk/BKR3TS/ https://talks.devopsdays.org/dodroxrox26/talk/BKR3TS/feedback/ Main Stage Other 2026-09-22T12:00:00-06:00 12:00 01:30 Menu to come. Please let us know if you have any dietary restrictions when registering. dodroxrox26-6548-lunch-day-1 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/ZJGUZL/ https://talks.devopsdays.org/dodroxrox26/talk/ZJGUZL/feedback/ Main Stage Talk 2026-09-22T13:30:00-06:00 13:30 00:30 Standardizing Kubernetes sounds straightforward — until different clouds, regulations, teams, and operational models start colliding. In this session, I’ll share lessons learned building a reusable Helm-based platform used across 4 cloud providers and 5 countries in financial environments. We’ll explore how readiness probes, affinity rules, and topology spread constraints helped improve reliability, but also where standardization created friction, unexpected operational challenges, and cultural resistance. This talk is less about “perfect Kubernetes” and more about the real engineering trade-offs behind platform consistency, resiliency, and scaling DevOps practices across distributed teams. dodroxrox26-6208-what-we-learned-standardizing-kubernetes-across-4-clouds Talks Marcello OzzettiFernando Carvalho en false https://talks.devopsdays.org/dodroxrox26/talk/KZLNKA/ https://talks.devopsdays.org/dodroxrox26/talk/KZLNKA/feedback/ Main Stage Talk 2026-09-22T14:00:00-06:00 14:00 00:30 Developers using GenAI tools ship 25% more tasks, accept a billion lines of AI-generated code per day, and are more productive than ever. So why are production incidents up 3x? This session shares what we found after analyzing incident trends across thousands of engineering teams and why the productivity gains from AI-assisted coding are creating an invisible reliability tax that most organizations aren't yet measuring. We'll walk through the Incident Rate Formula (λ + C × P): as AI accelerates the rate of change (C), the probability that any given change causes failure (P) becomes the only lever infra engineering teams can control. We'll look at how AI actually fails in production, echo chambers in unit tests, slop squatting attacks, hallucinated dependencies, and why the "angry intern" mental model is the most useful frame for working safely with LLMs. The talk closes with practical strategies for keeping P low: mutation testing at scale (Meta's 70%+ acceptance rate), AI-augmented code reviews, MCP-powered incident investigation, and where AI SREs are already handling Sev-2 and Sev-3 incidents autonomously. If you're building with AI or leading teams that are, this talk will give you a data-driven framework for staying fast without letting reliability quietly collapse. dodroxrox26-6207-ai-made-developers-25-more-productive-it-also-tripled-our-incident-rate Talks Sylvain Kalache en false https://talks.devopsdays.org/dodroxrox26/talk/HKGHAN/ https://talks.devopsdays.org/dodroxrox26/talk/HKGHAN/feedback/ Main Stage Break 2026-09-22T15:00:00-06:00 15:00 00:30 Coffee and other non-alcoholic drinks included all day. Snack list coming later. dodroxrox26-6782-snack-break-day-1 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/FYYFQA/ https://talks.devopsdays.org/dodroxrox26/talk/FYYFQA/feedback/ Main Stage Open Spaces 2026-09-22T15:30:00-06:00 15:30 00:30 Topic: Pay Talk Anonymously submit your salary and title before this session. Pay talk is about bringing transparency and awareness to our industry's market salary range and giving everyone the resources to discuss and fight for pay equality. Submit Here: [https://forms.gle/Jr69KLrLJNyQCuwr8 ](https://forms.gle/Jr69KLrLJNyQCuwr8 ) anytime before September 22, 2026, 3:00 PM MT dodroxrox26-6552-open-spaces-pay-talk Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/QVQYAZ/ https://talks.devopsdays.org/dodroxrox26/talk/QVQYAZ/feedback/ Main Stage Open Spaces 2026-09-22T16:00:00-06:00 16:00 00:30 Open Spaces - Day 1 - Session 2 - Stage dodroxrox26-6783-open-spaces-day-1-session-2-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/NNY8ZQ/ https://talks.devopsdays.org/dodroxrox26/talk/NNY8ZQ/feedback/ Main Stage Open Spaces 2026-09-22T16:30:00-06:00 16:30 00:30 Open Spaces - Day 1 - Session 3 - Stage dodroxrox26-6784-open-spaces-day-1-session-3-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/87U8LA/ https://talks.devopsdays.org/dodroxrox26/talk/87U8LA/feedback/ Main Stage Open Spaces 2026-09-22T17:00:00-06:00 17:00 00:30 Open Spaces - Day 1 - Session 4 - Stage dodroxrox26-6785-open-spaces-day-1-session-4-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/UCU7JC/ https://talks.devopsdays.org/dodroxrox26/talk/UCU7JC/feedback/ Main Stage Other 2026-09-22T17:30:00-06:00 17:30 02:30 Happy Hour dodroxrox26-6553-happy-hour-snacks Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/FEA9K7/ https://talks.devopsdays.org/dodroxrox26/talk/FEA9K7/feedback/ Main Stage Break 2026-09-23T08:00:00-06:00 08:00 01:00 Menu to come. Please let us know if you have any dietary restrictions when registering. dodroxrox26-6781-registration-sponsors-breakfast-day-2 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/XSNVRQ/ https://talks.devopsdays.org/dodroxrox26/talk/XSNVRQ/feedback/ Main Stage Talk 2026-09-23T09:15:00-06:00 09:15 00:30 Alert storms. Incident wars. Context-switching between Slack, PagerDuty, monitoring dashboards, and runbooks. We've built ops infrastructure that treats human attention like an infinite resource—and we're burning out trying to keep up. After 25 years in software development (total) and 10 in SRE/DevOps, I've watched attention fragmentation get worse with every tool we add. It costs teams: slower incident response, worse decisions, burnout. But it's fixable. This talk explores what it means to build systems that *respect* human attention constraints rather than ignore them—and gives you practical patterns to apply in your own org, whether you're building internal tools, evaluating new platforms, or rethinking your on-call workflow. dodroxrox26-6401-systems-that-respect-attention-redesigning-ops-for-human-limits Talks Abby Malson en **Elevator Pitch:** We've optimized ops infrastructure for speed and scale, but not for human attention. This is a framework—and practical patterns—for redesigning ops tooling around how people actually work. **Problem Statement:** Ops teams are drowning in interrupts. Alert fatigue, context-switching, pagerduty storms, Slack avalanches, runbook sprawl. Every tool we add promises to solve the last tool's problem and creates two new ones. The result: slower incident response, worse decision-making, and burned-out people. This isn't inevitable. It's a design choice. Most ops tooling is built as if humans have unlimited attention. **What This Talk Covers (30 minutes):** 1. **The Attention Crisis in Ops** (5 min) - How context fragmentation happens across incident response, on-call, runbooks, and monitoring - Why it matters: empirical connection to incident response quality, burnout, retention - This is not a people problem; it's a systems problem 2. **A Framework: Pull vs. Push, Ambient vs. Interrupt** (7 min) - Core distinction: systems that push notifications vs. systems you pull information from when you need it - The difference between "something happened and I need to decide now" and "I should be aware of this state" - Context assembly: moving this work from human brains to infrastructure - Decision logging: making patterns visible without requiring real-time attention 3. **Concrete Patterns in Practice** (13 min) - Designing ops surfaces for intentionality (TUI vs. web dashboards) - How to structure incident response around attention budget, not alert volume - Building runbook/context systems that assemble *only what's relevant* - Task/intent-driven ops: structuring on-call around actual work, not notifications - Real examples from building systems that respect these constraints 4. **What You Can Do Monday** (3 min) - Design questions to ask when evaluating new tools or processes - How to audit your current stack for attention respect - One pattern to start with if you're redesigning on-call or incident response **Who Should Attend:** - SREs and on-call engineers (this is your lived experience) - DevOps/platform engineers building internal tools - Tech leads and engineering managers concerned about team burnout - Anyone who's felt like their tools are fighting them instead of helping **Audience Takeaways:** - A vocabulary for talking about attention as a design constraint (like latency or cost) - Concrete patterns for redesigning ops workflows - A framework for evaluating whether a tool (or process, or on-call rotation) respects human limits - Permission to push back on "more monitoring" / "more alerts" as a solution false https://talks.devopsdays.org/dodroxrox26/talk/ARPBKK/ https://talks.devopsdays.org/dodroxrox26/talk/ARPBKK/feedback/ Main Stage Talk 2026-09-23T09:45:00-06:00 09:45 00:30 In a world where LLMs have become a central part of our toolchains, we as an industry are at a crossroads of figuring out how to best leverage non-deterministic systems for deterministic outcomes. In my recent experience, the best way to make LLM's have more useful output is to provide _just_ the right amount of context for an audit, feature development, or any other ask. In trying to best encompass the complexity of the many layers of systems from network to services to data, I envisioned and implemented a complex, dynamic architecture diagram and schema that our LLMs could use with skills to better assist our product developers in how we understand new feature development, cross-service constraints, data lineage, and more. dodroxrox26-6129-context-engineering-the-next-frontier-of-your-relationship-with-jarvis Talks Rainu Ittycheriah en false https://talks.devopsdays.org/dodroxrox26/talk/SXSXDJ/ https://talks.devopsdays.org/dodroxrox26/talk/SXSXDJ/feedback/ Main Stage Break 2026-09-23T10:15:00-06:00 10:15 00:45 Coffee and other non-alcoholic drinks included all day. Snack list coming later. dodroxrox26-6551-coffee-break-day-2 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/KUUWDH/ https://talks.devopsdays.org/dodroxrox26/talk/KUUWDH/feedback/ Main Stage Ignite 2026-09-23T11:00:00-06:00 11:00 00:05 For organizations undergoing digital transformation, adopting multiple frameworks like DevOps and ITIL often leads to a "too many cooks in the kitchen" issue, blurring the benefits of both. A successful digital transformation requires knowing exactly how much of each ingredient to use, and when to mix them. This talk explores how the new ITIL version 5 Digital Product Service Management lifecycle and the infinite DevOps loop complement each other. Moving past traditional framework rivalry, we will analyze where these methodologies collide and where they create powerful synergies. Drawing from personal enterprise experience, attendees will leave with practical, situational "recipes"—step-by-step blueprints demonstrating how to combine DevOps and ITIL version 5 to accelerate delivery velocity without sacrificing organizational stability. dodroxrox26-6387-a-recipe-blending-the-devops-infinite-loop-and-the-new-itil-diamond-tiles Ignite Talks /media/dodroxrox26/submissions/DFZH3R/image_8xjPDa3.webp Catherine Bordinat en Too Many Cooks? Blending DevOps and ITIL version 5 Without Burning the Kitchen Blindly implementing both DevOps and ITIL usually leads to conflicting processes and frustrated teams. It doesn't have to be that way. Drawing from real-world banking transformations, this Ignite talk serves up a step-by-step "recipe" to seamlessly integrate DevOps pipelines with the new AI-native ITIL version 5. In 20 auto-advancing slides, you'll learn how to combine both framework through real world experience and step by step approaches mixing CI/CD pipeline and lighter change management, enabling feedback loop with monitoring and observability and more. false https://talks.devopsdays.org/dodroxrox26/talk/DFZH3R/ https://talks.devopsdays.org/dodroxrox26/talk/DFZH3R/feedback/ Main Stage Ignite 2026-09-23T11:05:00-06:00 11:05 00:05 Terraform plan tells you what changed. It doesn't tell you what matters. In 5 minutes, I'll show how classifying drift by severity separating security group changes from tag updates cut our alert noise by 73% while catching 94% of security-relevant changes. Includes a live demo of tfdrift, the open-source tool I built to solve this. dodroxrox26-6092-our-terraform-plan-output-is-lying-to-you-by-omission Ignite Talks Sudarshan Bhagvan en false https://talks.devopsdays.org/dodroxrox26/talk/BZZTJ8/ https://talks.devopsdays.org/dodroxrox26/talk/BZZTJ8/feedback/ Main Stage Ignite 2026-09-23T11:10:00-06:00 11:10 00:05 The Krebs Cycle turns glucose into ATP. CI/CD turns code into deployments. Both are energy-intensive, feedback-driven, and fail without oxygen (or tests). Let’s compare cellular respiration to DevOps pipelines! dodroxrox26-5860-the-devops-metabolism-how-ci-cd-is-like-the-krebs-cycle Ignite Talks Sophia Solomon en The tools we need to create better CI/CD pipelines are already within us - literally! By breaking down the building blocks to metabolism in the body, I want to show Engineers that biological science and computer science are inherently interconnected. If we can break down pipelines in the same way, we can see how to automate in the same efficient way that all of our bodies already do. false https://talks.devopsdays.org/dodroxrox26/talk/WK7EER/ https://talks.devopsdays.org/dodroxrox26/talk/WK7EER/feedback/ Main Stage Ignite 2026-09-23T11:15:00-06:00 11:15 00:05 Documentation is one of it not the most neglected spaces in software engineering. We refuse to take care of it but everyone can relate to the frustration of needing up to date docs when it matters but they haven’t been updated or tested for correctness in years. READMEs, onboarding guides, and operational runbooks are often treated as static artifacts. Over time they drift from reality — even as the platform itself evolves. However, as we incorporate LLMs and coding agents directly into our environments, the very same docs that we haven’t cared about, are the exact context agents are using to build our apps. In this talk, I’ll explore documentation as an unverified surface within Internal Developer Platforms, and explain why context retrieval and compression, are only two parts of a 3 legged stool . We’ll cover: • Why documentation drift increases cognitive load and support tickets • Why unverified docs as context lead to unnecessary spending • Why valid and up to date docs against the system they are for is no longer a nice to have but a systemic necessity • What time and money is saved when shifting left the responsibility of validation from the agents. dodroxrox26-5819-context-validation-doc-testing-and-the-missing-ai-infrastructure-layer Ignite Talks Omari Gaskins Jr en false https://talks.devopsdays.org/dodroxrox26/talk/CWCSVS/ https://talks.devopsdays.org/dodroxrox26/talk/CWCSVS/feedback/ Main Stage Ignite 2026-09-23T11:20:00-06:00 11:20 00:05 Odysseus took ten years to get home. Your software just needs to reach production, but the voyage is every bit as cursed. In this Ignite-paced romp through Homer's *Odyssey*, we sail the platform engineer's ship past a gauntlet of monsters, each one a hazard you have already met under a different name: the Lotus-Eaters of "we've always done it this way," the one-eyed Cyclops of zero observability, Aeolus's bag of winds (a.k.a. Friday night deployments), the impossible trade-off of Scylla and Charybdis, the Sirens of shiny IT-ops nostalgia, and the sacred Cattle of the Sun you were explicitly told not to touch. The lesson Odysseus learned the hard way, lash yourself to the mast, is the same discipline that gets your developers safely home to a platform they actually love. dodroxrox26-6409-lashed-to-the-mast-a-platform-engineer-s-odyssey Ignite Talks Luke Philips en false https://talks.devopsdays.org/dodroxrox26/talk/DBHC79/ https://talks.devopsdays.org/dodroxrox26/talk/DBHC79/feedback/ Main Stage Talk 2026-09-23T11:30:00-06:00 11:30 00:30 DevOps did not begin as a profession. It began as a response — a grassroots reaction to the friction between development and operations, to slow delivery cycles, brittle releases, and organizational silos that separated software creation from software operation. Early practitioners were not building a discipline; they were solving urgent, real-world problems. Yet from those experiments and shared learnings, something remarkable emerged: a movement grounded in outcomes rather than prescriptions. This talk traces the arc of that transformation — from scattered, individual practice to an enterprise-scale professional capability. It examines how DevOps crossed critical thresholds: the adoption of shared language (value streams, deployment frequency, SLOs), the emergence of guiding frameworks like the Nine Pillars of DevOps, and the formalization of learning paths and certifications that allow practitioners to grow not just as technicians, but as strategic contributors. Central to this evolution is a tension every maturing discipline must navigate: how do you establish standards without imposing rigidity? DevOps has always thrived on adaptability. A financial services firm, a healthcare provider, and a technology startup each implement DevOps differently — and they should. The profession must accommodate that diversity while maintaining coherence at its core. This session explores how that balance is being struck today. Attendees will leave with a clearer picture of where DevOps stands as a profession, what the road ahead looks like as AI and platform engineering reshape the landscape, and — most practically — how to position themselves and their organizations to grow with it. Whether you are a seasoned practitioner, an engineering leader, or someone just beginning this journey, this talk offers a grounding perspective on what DevOps is becoming and why it matters. dodroxrox26-6063-from-practice-to-profession-devops-in-the-ai-native-era Talks /media/dodroxrox26/submissions/3CDUSJ/image_Qz3n2Zl.webp Marc Hornbeek en DevOps did not begin as a profession. It began as a practical response to a painful problem. Development and operations were separated. Releases were slow. Production was fragile. Security arrived late. Feedback arrived later. Teams worked hard, but the system of work made reliable change unnecessarily difficult. DevOps changed that. It gave the industry a better way to think about flow, collaboration, automation, feedback, reliability, security, and continuous improvement. What started as a grassroots movement has now become an enterprise capability. The next step is even more important. DevOps must now mature into a profession. That need has become urgent because AI is changing the speed, scale, and risk of software delivery. AI-assisted engineering can generate code, tests, configurations, documentation, operational summaries, and deployment recommendations faster than traditional delivery systems were designed to absorb. The problem is no longer whether teams can move faster. The problem is whether organizations can validate, secure, govern, release, observe, and improve that work with enough discipline to produce trustworthy outcomes. In the AI-native era, immature DevOps becomes a risk multiplier. Tools alone will not solve this. Pipelines alone will not solve this. Cloud platforms alone will not solve this. AI assistants alone will not solve this. Organizations need a mature DevOps operating model that integrates people, practices, platforms, automation, governance, measurement, and continuous learning. They need internal developer platforms that reduce cognitive load while embedding guardrails. They need pipelines that integrate both human-generated and AI-generated artifacts into a unified flow of validation. They need continuous testing, continuous security, observability, provenance, audit trails, risk-based deployment decisions, and feedback loops that connect production learning back into engineering decisions. This talk will introduce the forward-looking vision for DevOps as a modern profession, as an organization-wide system for value delivery and positions AI-native DevOps as the next stage of professional maturity. The talk will emphasize the need for shared language, standards without rigidity, learning paths, platform engineering, embedded governance, pipeline integration, value stream management, and DevOps maturity assessment. The message is simple: DevOps is not becoming less important because of AI. DevOps is becoming more important because of AI. As AI increases the speed and volume of change, the profession must raise the standard for validation, governance, reliability, security, observability, and accountability. The future belongs to organizations that can combine AI-native engineering with mature DevOps discipline. Attendees will learn: - Why AI-native software delivery requires mature DevOps, not less DevOps. - How platform engineering becomes a scaling layer for enterprise DevOps. - Why pipelines must evolve to validate both human and AI-generated work. - How DevOps connects Agile, DevSecOps, SRE, platform engineering, governance, and value stream management into one operating system for value delivery. - Why DevOps needs shared language, assessment models, learning paths, and professional standards. - The DEVOPS INSTITUTE® Official DevOps book which can be used as a vendor-neutral reference for leaders, practitioners, coaches, assessors, and educators for building mature, AI-ready DevOps capability. DevOps began as a movement. It became a practice. Now, in the AI-native era, it must become a profession. false https://talks.devopsdays.org/dodroxrox26/talk/3CDUSJ/ https://talks.devopsdays.org/dodroxrox26/talk/3CDUSJ/feedback/ Main Stage Other 2026-09-23T12:00:00-06:00 12:00 01:15 Menu to come. Please let us know if you have any dietary restrictions when registering. dodroxrox26-6549-lunch-day-2 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/FUHGH8/ https://talks.devopsdays.org/dodroxrox26/talk/FUHGH8/feedback/ Main Stage Talk 2026-09-23T13:45:00-06:00 13:45 00:30 3 years ago, we expanded our engineering organization by incorporating two teams located on a different continent. Suddenly, we had to adopt a new working style: juggling multiple time zones, managing cultural differences, dealing with increasing ambiguities while maintaining delivery pace. During this session, we will explore the difficulties we encountered in this scale-up phase. We will share how Team Topologies guided our team restructuring for optimal cognitive load and faster flow. We'll share our painful mistakes and how we leveraged insights from The Culture Map to bridge cultural communication gaps and foster trust across continents. Finally, we will show how integrating Non-Violent Communication (NVC) principles enabled us to turn conflict and ambiguity into productive conversations. By the end of this presentation, you’ll have a clear understanding of the structural, cultural, and communication practices that help a technical organization scale successfully across continents. dodroxrox26-5977-scaling-engineering-teams-across-continents Talks Ludovic Toison en A review of the lessons learned in building and managing a technical organization of 30 developers arranged into 4 feature teams, operating across two continents (Europe and Asia), two time zones (GMT+2, GMT+7), and representing 9 different nationalities. false https://talks.devopsdays.org/dodroxrox26/talk/HMEDVS/ https://talks.devopsdays.org/dodroxrox26/talk/HMEDVS/feedback/ Main Stage Break 2026-09-23T14:30:00-06:00 14:30 00:30 Coffee and other non-alcoholic drinks included all day. Snack list coming later. dodroxrox26-6789-snack-break-day-2 Food/Drinks en false https://talks.devopsdays.org/dodroxrox26/talk/RYBRAY/ https://talks.devopsdays.org/dodroxrox26/talk/RYBRAY/feedback/ Main Stage Open Spaces 2026-09-23T15:00:00-06:00 15:00 00:30 Open Spaces - Day 2 - Session 1 - Stage dodroxrox26-6786-open-spaces-day-2-session-1-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/CQWAED/ https://talks.devopsdays.org/dodroxrox26/talk/CQWAED/feedback/ Main Stage Open Spaces 2026-09-23T15:30:00-06:00 15:30 00:30 Open Spaces - Day 2 - Session 2 - Stage dodroxrox26-6787-open-spaces-day-2-session-2-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/CSWHBN/ https://talks.devopsdays.org/dodroxrox26/talk/CSWHBN/feedback/ Main Stage Open Spaces 2026-09-23T16:00:00-06:00 16:00 00:30 Open Spaces - Day 2 - Session 3 - Stage dodroxrox26-6788-open-spaces-day-2-session-3-stage Open Spaces en false https://talks.devopsdays.org/dodroxrox26/talk/LAAJVL/ https://talks.devopsdays.org/dodroxrox26/talk/LAAJVL/feedback/