Dev vs. Ops, DevOps, and SRE
The Dev vs. Ops split, DevOps, and Site Reliability Engineering are examples of three different approaches used by companies to structure work: Specialisation, convergence, and split incentives.
Organisational structure is a tool for companies to solve problems and improve performance of the organisation. But depending on what aspect the company concentrates on, different structures can emerge as part of solving the same problem.
If we compare Dev/Ops, DevOps and SRE, these three approaches are a way of addressing the operations problem (the problem that someone has to run software in production), but using different tools in the organisational toolkit.
The Dev/Ops split is a specialisation split. If Dev work and Ops work are substantially different in terms of skills required, it makes sense for organisations to split these between two different groups of people. It makes it easier to hire people (because you don’t have to find people that have a combination of all the skills required), it allows you to scale the two organisations at different rates, and maybe you can even pay the two groups of people different salaries.
The DevOps approach is convergence-based, so it goes in the opposite direction: If there is not much difference between two kinds of work, maybe you can be more efficient by combining the two kinds. This is particularly attractive for small organisations that don’t have the means to staff two separate groups for doing two kinds of work that are pretty similar to each other.
Site Reliability Engineering on the other hand is neither specialisation nor convergence. It’s an incentive split. One of the fundamental problems of organisational psychology is that people have a really hard time keeping conflicting goals in mind and trading off between them. People can really only concentrate on one top priority at a time. If you want a (sufficiently large) company to concentrate on more than one goal, and some of those goals conflict with each other, then there’s a structural way of dealing with this: Split the two conflicting goals among two teams, and have the two teams hash them out and achieve a compromise.
This might explain why it’s hard for companies to switch from a Dev/Ops split or from DevOps to SRE. You can’t simply take departments that were created for a different reason and repurpose them to solve a different problem. Or take people that you used to incentivise differently and basically pit them against their former selves.
