DevOps After the Remote Shift: A Conversation with Lightstep’s Ben Sigelman
DevOps turned ten years old recently, and while its underlying goals haven’t moved, the practices are still in flux. Ben Sigelman, CEO of observability vendor Lightstep, talked with us about where the discipline is heading, why automation is not the point, and how a year of remote work has reshaped operational priorities.
The Next Five Years: Consolidation, Not Innovation
Sigelman describes the current DevOps landscape as a paradox: an overwhelming number of tools—he points to the CNCF Landscape as evidence—combined with little agreement on how to actually run DevOps. That’s not necessarily a problem, but he expects the next five years to bring sharper definitions and success criteria for everything from CI/CD to observability. More importantly, he predicts the emergence of a few opinionated, holistic frameworks that organizations can adopt rather than assemble from scratch. The payoff, he argues, will be less time spent experimenting with tooling and more time shipping products.
Automation Is a Side Effect, Not the Goal
It’s tempting to equate DevOps with automating everything, but Sigelman pushes back on that shorthand. The real driver, he says, is parallelism—the ability for one person to take a backlog item all the way to production without waiting on anyone else, especially the slowest and least reliable component in any organization: other humans.
“The big change for DevOps is giving individuals enough scope to develop, secure, deploy, and operate their own piece of a larger software application while minimizing the number of roundtrip communications with other people.”
Once dependencies on other people are removed, any good engineer will naturally automate what remains. That’s why automation has been such a visible outcome of DevOps, but it’s a consequence, not the definition.
Remote Work Accelerates the Shift to Self-Service
The forced move to fully remote work last year reinforced the need for self-reliance and parallelism. It also made the old way of operating impractical—you can no longer walk over to the in-house expert when production breaks. Even if you find them on Slack, it’s easier for them to ignore you.
Meanwhile, the pace of production changes keeps climbing, and every change introduces new interactions and failure modes. Sigelman sees observability tooling moving toward systems that can take an unplanned change as input and dynamically suggest possible explanations, without requiring someone to track down the “expert” who understands the whole system. Remote work, he says, is accelerating that evolution.
The Rise of the Individual Operator
Before DevOps, shipping an improvement required multiple teams and organizations. The most transformative aspect, in Sigelman’s view, is the independence this gave individual developer-operators. As a result, organizations are deploying software hundreds of times more frequently than they used to—a change that compounds culturally and technically over the years.
Why DevSecOps Isn’t the Answer
On the question of whether security will absorb into DevOps or remain a separate discipline, Sigelman takes a contrarian stance: he’s not a fan of the term DevSecOps.
He acknowledges that many security practices—automated package vulnerability testing, real-time threat detection, configuration auditing—fit naturally into a developer’s workflow, and that much of “dev” and “ops” can be consolidated into one role. But security involves attack vectors far outside the software development lifecycle: corporate email, spear phishing, edge network compromises, DDoS, and supply chain attacks like the recent SolarWinds incident. Those parts of a CISO’s responsibility cannot be handled by the person writing and deploying a service. Security will certainly become one aspect of the “Ops” in DevOps, but Sigelman sees DevSecOps as a misleading label.
Full Ownership, No Separate Ops Team
Asked what successful DevOps looks like at Lightstep, Sigelman says his experience at Google convinced him that having a separate ops or SRE organization is the wrong model. Reliability and product goals should be balanced by a single team with a single strategy—not split across org charts.
Still, there’s no universal structure. As Lightstep’s engineering, product, and design organization grows, the team continuously reassesses whether people feel responsible for what they control and whether operational scope matches development scope. “Making it” is never durable, Sigelman admits, but the goal is to stay introspective and address problems before they turn into crises.
Asking the Harder Question
One thing DevOps practitioners rarely consider, Sigelman says, is that their teams don’t operate in the cheerful independence the theory suggests. Services depend on and interact with other services in unexpected ways. With thousands of changes going to production weekly, the real challenges are planning so your “independent” improvements don’t break another team’s service—and responding effectively when your own service fails because of someone else’s change.
The industry needs more robust and dynamic ways to understand cross-service impact, which is where observability increasingly fits in.
