Feedback loops are very important to regulate behavior within an enterprise. This applies to both rewarding positive behavior, and encouraging more of it, as well as correcting negative behavior to get less of it. Continuous improvement is about feedback loops.
Focusing on negative feedback, we should recognize a phenomenon called ‘pain’. In this context, it refers mostly to pains in the ass, which are discomforts, inconveniences, and frustrations which burden people’s life, draining their time and energy in unproductive ways. In DevOps, when high severity operational problems arise, such a service outage in the middle of the night, pain manifests in a pager alert that wakes up an engineer to troubleshoot the incident and resolve the problem.
When fires need to be fought, fire-fighters experience this pain in proportion to the number of fires and their severity. Development teams tend to avoid work with the goal being to deliver features with faster time to market. They inevitably cut corners in areas that make operations more efficient, because they tend not to be placed in the position of experiencing the pain, when it comes. Disconnecting development priorities from operational responsibilities is a recipe for the infliction of pain on those who do not deserve it, and the result is an excess of unexpected pain that should have been foreseen and mitigated. The integration of development with operations into DevOps is intended to establish this connection. This connection must not be undermined by paying mere lip-service to operations without putting real skin in the game, so that development staff experience pain for operational failures as much as operations staff.
To be fair, I don’t believe most developers would intentionally neglect non-functional requirements, such as enabling services to be more manageable operationally. As we see with other non-functional requirements for security, telemetry, and deployment cost, it is often management who directs development staff to invest as much effort as possible into delivering features, while withholding as much resourcing as possible to these other architectural concerns, because they are viewed as “overhead” or someone else’s problem. When teams are organized along functional lines, they are seen as earning credit for delivering on functional scope, and all else are unwanted costs or impediments toward that goal. This may be where the failures (delivering feature-rich services that are painful to operate) usually lie.