Put developers on-call to help management understand the importance of operations

Many people advocate for developers being on-call. One argument is better code and maintainable systems because devs start caring about testing, monitoring, logging and many things we associate with “operations.”

This is true. But this does not happen just because developers feel the pain of getting up 2am in the morning. It goes well beyond hurting developers.

A lot of managers have a hard time understanding what it takes to build robust and maintainable systems. They see developers as feature factories and demand a lot in such a short period of times.

As the expectations arise, developers have to start pushing more and more untested, undocumented, and often not monitored code. This leads to more problems on ops side but that is their job. So, devs and management can live with that — until they can’t.

BUT, when developers start getting the alerts and spend their time on “operations”, it becomes a lot easier for managers to see the business impact of “fast code.”

At this point, some managers might blame developers for being lazy or incompetent — instead of looking at things from a different angle. That is a whole different issue, and I saw and heard many companies doing that. That is toxic and don’t work there.

Now management has a metric showing them how much the feature factory approach is costing them — costing devs.

Hopefully, they start looking into making apps more robust and eventually start reading about #DevOps.

In the past, I was thinking if a company doesn’t have some monitoring setup and have at least dealt with some important things like CI/CD, versioning, they shouldn’t put devs on-call. Now, I think the opposite.

Put devs on-call first, so it becomes a lot easier for managers to see the business impact of bad code and operational practices. Then start iterating from there.