The On-Call Rotation the CPO Never Sees

The on-call rotation is the most honest expression of how a product organization actually relates to its engineering team. Not the values poster, not the engineering blog post, not the all-hands slide about technical excellence. The on-call rotation: how often engineers get paged, at what hour, for what reason, and what happens to them the next day.

Most product leaders — even the technically sympathetic ones — have a abstract relationship with this. They know on-call exists. They understand it’s burdensome in some generalized way. They accept that reliability work competes with product work and they try to make room for it. What they don’t see is the specifics: the engineer who was paged three times in one week because a monitoring threshold was misconfigured and nobody had time to fix it. The rotation that’s effectively two people deep because the rest of the team doesn’t know the legacy service well enough to be on-call for it. The alert that fires every Tuesday at 3am for a reason that everyone on the team has stopped trying to understand because it resolves itself.

Those specifics are the product of product decisions. Not solely, but meaningfully. The legacy service that nobody knows is a legacy service because the product roadmap never had room for a rewrite. The misconfigured threshold exists because the team didn’t have time to tune it after the rushed deployment. The self-resolving alert is self-resolving because the underlying condition is a known architectural issue that’s been de-prioritized for eight consecutive quarters. Every one of those items has a product decision upstream of it.

The attrition signal

On-call quality is one of the best leading indicators of engineering attrition I’ve found, and it’s one of the least watched. Engineers who are chronically on-call for unreliable systems in organizations that don’t fix the underlying problems are telling themselves a story about their employment: that they’re being asked to absorb organizational failure as a personal cost, repeatedly, with no sign of relief on the horizon.

This story doesn’t usually produce a resignation letter with “on-call burden” in it. It produces a general erosion of engagement, followed by a quiet job search, followed by a resignation that gets coded as “going for a better opportunity.” Which is true. But the opportunity often involves a more reliable system or a healthier on-call culture more than it involves a title change or a salary bump.

The signal to watch is not the aggregate number of pages per week. It’s the median time between a recurring alert and the ticket that fixes its root cause. If that number is measured in months, or if recurring alerts don’t generate root cause tickets at all, you have an organizational dysfunction that will eventually express itself in attrition.

What a CPTO can actually do

The intervention isn’t to personally review the on-call rotation, which is too tactical to be a durable senior leadership behavior. It’s to make the reliability conversation structurally equal to the feature conversation in the rooms where prioritization happens.

That means having a standard representation in product reviews for reliability work. Not as a separate track — “engineering reliability roadmap” alongside the product roadmap — but integrated into the same prioritization conversation, with the same level of business justification required and the same level of leadership attention applied. “Addressing the authentication service instability that’s currently producing 14 hours of on-call burden per engineer per month” should compete for capacity on the same terms as any feature.

The second thing it means is that the CPTO has to ask, occasionally and specifically, “what is the on-call experience like right now?” Not in a survey or in an all-hands. In a direct conversation with engineers who are currently on-call. The answers to that question, heard directly rather than filtered through management summaries, will tell you things about the health of the system that no dashboard will show you.