### The Murphy-Beyer Effect

Related to a discussion my colleague Betsy and I had the other day, I was led to the following observation:

The end state of an SRE team that acquires new work and automates this new work as much as possible is to have only non-automatable (or practically non-automatable) work remaining.

What do I mean here? It's a little like the operational analogue of Amdahl's law. From parallel computing, Amdahl's law is a description of the limits of how much a computation can be sped up, given some description of what proportion of it is not parallelizable. There are a number of underlying reasons for this, of course, and it turns out that it is much less of an effective limit on the benefits of parallelization than it sounds, but it came to mind when I was thinking about SRE teams workstreams the other day.

To put it another way, a similar analogue for operations is the observation that the proportion of SRE work for a service which is

The end state of an SRE team that acquires new work and automates this new work as much as possible is to have only non-automatable (or practically non-automatable) work remaining.

What do I mean here? It's a little like the operational analogue of Amdahl's law. From parallel computing, Amdahl's law is a description of the limits of how much a computation can be sped up, given some description of what proportion of it is not parallelizable. There are a number of underlying reasons for this, of course, and it turns out that it is much less of an effective limit on the benefits of parallelization than it sounds, but it came to mind when I was thinking about SRE teams workstreams the other day.

To put it another way, a similar analogue for operations is the observation that the proportion of SRE work for a service which is

*non-automatable*comes, over time, to dominate wh…