Engineering Note
If the same engineer gets paged every time production breaks, you don't have an on-call process. You have a dependency.
In a small SaaS team, this happens easily.
One engineer knows the Rails application inside out.
Another knows AWS.
Someone else understands the database.
So when production has an issue, the same person gets the call.
We faced this too.
The fix wasn't hiring more people.
We changed how responsibility was shared:
* Clear weekly on-call rotation
* Runbooks for common incidents
* Alerts with enough context to act on
* No unnecessary pages
* Post-incident knowledge shared with the whole team
The goal wasn't to make everyone an expert in everything.
It was to make sure no critical system depended on one person's memory.
After a few rotations, engineers became more comfortable handling incidents outside their usual areas.
The bigger benefit?
Fewer late-night escalations to the same person.
Important learning:
A sustainable on-call setup isn't about spreading pain equally.
It's about spreading knowledge and responsibility across the team.
One engineer knows the Rails application inside out.
Another knows AWS.
Someone else understands the database.
So when production has an issue, the same person gets the call.
We faced this too.
The fix wasn't hiring more people.
We changed how responsibility was shared:
* Clear weekly on-call rotation
* Runbooks for common incidents
* Alerts with enough context to act on
* No unnecessary pages
* Post-incident knowledge shared with the whole team
The goal wasn't to make everyone an expert in everything.
It was to make sure no critical system depended on one person's memory.
After a few rotations, engineers became more comfortable handling incidents outside their usual areas.
The bigger benefit?
Fewer late-night escalations to the same person.
Important learning:
A sustainable on-call setup isn't about spreading pain equally.
It's about spreading knowledge and responsibility across the team.