Skip to main content
DevOps is the set of practices, culture, and tooling that brings development and operations teams together to deliver software faster and more reliably. Before DevOps, these were often separate functions with separate goals - developers wanted to ship changes, operations wanted stability. The incentives were in direct conflict 🔧

​
The core idea

DevOps removes the handoff. Instead of developers throwing code over a wall to an operations team to deploy and maintain, the same team owns the full lifecycle - build, test, deploy, monitor, operate. “You build it, you run it.” This changes how teams think about quality. When the people who write the code are also the people who get paged at 2am when it breaks, the incentives for reliability shift dramatically 💡

​
Key practices

Continuous integration (CI) - developers merge code frequently, with automated tests running on every commit. Catches problems early, keeps the codebase in a deployable state. Continuous delivery (CD) - the pipeline from code commit to production is automated and can be triggered at any time. Doesn’t mean you ship every commit - means you could. Infrastructure as code - environments are defined and managed through code, not manual configuration. Reproducible, version-controlled, consistent across dev, staging, and production. Monitoring and observability - the team has visibility into what’s happening in production. Errors, latency, usage patterns. You can’t operate what you can’t see. Feature flags - ship code without exposing features, enable gradual rollouts, kill switches for problems. Decouples deployment from release (see release management).

​
Why PMs should care

DevOps capability directly affects how fast you can learn. A team that deploys once a fortnight can run one experiment per cycle. A team that deploys ten times a day can run experiments continuously and get signal in hours, not weeks. It also affects risk. Frequent small deployments are safer than infrequent large ones - there’s less to go wrong and less to roll back when something does 🙌 Mik Kersten traces the broader organisational shift in Project To Product - DevOps is part of the move toward flow-based delivery that treats software as a continuous value stream, not a series of projects. Lesson learned: the teams shipping the best products I’ve seen aren’t the ones with the most rigorous planning - they’re the ones who can safely ship ten times a day and roll back in minutes when something goes wrong.