At DevOpsDays Tokyo, the Q&A format let me dig into questions I don’t usually get to address in a structured talk. The first one is always the same: what is DevOps? My working definition has evolved over the years to something simple: removing friction between silos. All the rest is engineering. That framing works because it applies regardless of which silos you’re dealing with – dev and ops, dev and security, product and engineering, or any other organizational boundary where handoffs create waste.
The naming story surprises people. I wanted to organize a conference about agile practices applied to system administration. “Agile System Administration Days” was too long for a Twitter hashtag, so I shortened it to “DevOpsDays” and “DevOps” emerged from that. I deliberately never wrote a formal definition or manifesto. The moment you pin down exactly what DevOps is, you limit what it can become. The ambiguity was a feature, not a bug – it let different communities find their own way to the core ideas.
The paradoxes in DevOps fascinate me. Automation is the most obvious one: we automate to reduce human error, but the automation itself introduces new failure modes and requires its own operational discipline. Security is another paradox – adding security controls is supposed to reduce risk, but badly implemented security slows teams down so much that they start cutting corners, which increases risk. The customer-centric drift is a subtler one: organizations adopt DevOps to serve customers better but end up optimizing internal metrics that drift away from actual customer value.
Operations doesn’t disappear as abstractions rise – it shifts. When you went from managing physical servers to virtual machines, the operational surface changed but didn’t shrink. Same with containers, same with Kubernetes, same with managed services. Every abstraction layer creates new operational concerns at a different level. The people doing ops might have different titles and use different tools, but the discipline of keeping systems running reliably remains essential at every layer.
The question about explaining DevOps to management crystallized something I’ve learned the hard way: never lead with the word “DevOps.” Lead with the business problem. Executives care about time to market, reliability, customer satisfaction, and cost. Frame your proposal in those terms, show the evidence, and let the practices speak for themselves. The label matters to us as practitioners; it’s meaningless to a CFO.
Watch on YouTube — available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.