… whereas I&#x27;d conversely argue that volumes are also spoken when a company does not require its developers to be on-call. Often, those volumes are written with negative undertones and a narrative that speaks to developers not owning or understanding their software stack. Worse, in an exercise reminiscent of companies offering unlimited PTO, &quot;not on-call,&quot; when read between the lines, could really mean &quot;always on-call.&quot; I currently work with teams that operate this way, and the amount of burnout is staggering.<p>As someone who has leapt between development and operations time and time again, I can anecdotally say that the systems where developers felt like they had ownership stake (including a desire to know &quot;what went wrong,&quot; often only accurately conveyed via an OC shift) were better designed, better maintained, had longer MTBF and had dramatically shorter MTBR.<p>That doesn&#x27;t mean that the development team that engineered the system in the first place should always be the first line of defense; rather, it means that there should still be some sort of escalation tier in case the operations team to which the service has been handed off needs some further assistance. I can recount stories for days wherein I was frustrated as someone in operations that I couldn&#x27;t reach someone from a development team in the middle of the night for a critical service--where VP- and SVP-levels were barking at me to fix it--only to hijack repository permissions and write patches myself for their software. It should go without saying, naturally, that reprimands for such heroic acts (heaven forbid I actually fix the damn thing) were definitely forthcoming the next morning.<p>That whole mess is wrong and anti-collaborative. Without the guardrails of a well-defined on-call shift, this is what no-on-call organizations devolve to.<p>This all comes with a caveat though: Again, anecdotally, I&#x27;ve found that tossing the development team to the fire for the first six or so months of a service&#x27;s production lifetime, before even allowing them to ask for operations handoff, pays dividends in terms of meeting (or exceeding) business goals, keeping operations&#x27; frustrations low, and delivering a quality service that other teams can rely on. This goes in concert with automated unit&#x2F;functional&#x2F;whatever testing, knocking parts over in production in a controlled manner, continuous reviews of documentation, commit-gating code reviews, monitoring that makes sense, and so on and so forth.<p>(As an aside, folks on the operations side have enough to worry about in terms of integrating all of the infrastructure to make everything appear to Just Work™. Adding the burden of having to reverse engineer tossed-over-the-wall &quot;It&#x27;s an ops problem now&quot; garbage is akin to the trend in the initial days of the devops movement for operations folks to toss systems automation over the wall to developers. It&#x27;s disrespectful. Work together. Show trust and solidarity by carrying a pager alongside the ops guys to say, &quot;Yes, I&#x27;m right here with you in case you need me.&quot;)<p>Tom Limoncelli somewhat recently put out &quot;The Practice of Cloud System Administration&quot;[0], and I implore that you give it a cover-to-cover read. Even folks who align with the development side of the house will get some benefit from it.<p>Finally, to your point about testing in a non-production environment: Even with a barrage of testing in staging or QA, you will still find problems in your software that only exist in production, and it won&#x27;t be for lack of trying to unify fiddly things like configuration parameters or runtime versions.<p>0: <a href="http:&#x2F;&#x2F;the-cloud-book.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;the-cloud-book.com&#x2F;</a>