> this person typically just becomes the “whipping boy” for the team. That sounds like a culture problem to me. SRE is just a fancy name for a class of people

> this person typically just becomes the “whipping boy” for the team. That sounds like a culture problem to me. SRE is just a fancy name for a class of people that make stuff more reliable. However it appears the reader of this book forgot about the other part: making stuff easy to use. Everywhere I have worked in the last 10 years has had an embedded sysadmin/devop/SRE/PE of some sort. They are there to take the raw, difficult to use tools and adapt them so that developers are able to deploy without hand holding. This means evangelising metrics, showing how to manage alerting, coordinating standards and leading incident responses. The symptoms the writer describes are of a dysfunctional dev environment. Ideally your SRE should be able to rotate teams quickly. That means standards. Once a team is setup and running, they shouldn't really need ongoing SRE functions, unless they are making massive changes. This can only happen if developers are re-using tools, rather than making new wheels out of space age materials and getting bored and moving onto new things.