Paid Interventions

Working overtime should not be a standard. We don't want you burned out, frustrated, tired, and sad. In general, we would like to foster a healthy work-life balance environment and encourage everyone to work the usual work hours. Overtime work has to be agreed upon and approved by your line manager in advance. Overtime is compensated by being paid or by taking time off as compensation for the hours you worked.

We have two types of overtime:

• Readiness

• Intervention.

Some teams in the company and some developers holding critical services sign a contract addendum where they are responsible for being on call a certain number of days in a month, meaning they need to be available to answer a call within 10 minutes and start working on an issue in a maximum of half an hour. This is compensated in itself even if no calls arrive. Concerning interventions, in the majority of teams, they happen rarely.

Readiness and Intervention in Practice

Check these three examples to see how readiness and interventions function in practice:

• Readiness: I'm an Engineer in our API team which is the owner of critical API endpoints. I signed a contract addendum for readiness. In my team, we are all in a readiness rotation, and every day we change who is on duty after working hours. We are all compensated for being in a readiness state. This day I'm on duty. One endpoint of our public API is returning the error and I'm called by OpsGenie, the automated alerting and incident response tool, to check what is the issue. I checked in on the #incident_management Slack channel within 10 minutes and started working on the issue. The issue was in the last deployment, I fixed it and let the support know which clients and how much traffic were affected.

• Unplanned intervention: I'm an Engineer in our internal team who works on SuperUser product, an internal tool that is used by Support and Account Managers. Incidents happen rarely on the services which my team is owner, from 1 to 10 times per year. I'm called outside of working hours by our Support team who have exhausted all typical troubleshooting steps they usually go through. Our product isn't accessible. In Engineering we are responsible to fix what we build and at that time I was at home and I checked in on Slack and started to see what is the root cause. I solved the issue and deployed a new version of the application in production. After that, I filled out our internal form with a ticket that I worked on and the start and end date so I can get compensated for the hours I was online.

• Planned intervention: I'm an Engineer in the team who works on our Contact Center solution and we have scheduled database migration during the weekend in order to lower the impact on customers. I agreed with my team members that I will be responsible for checking if everything is ok with database migration for Contact Center. I was online during one period of the weekend when migration happened and everything went ok with it. After the migration, I filled our internal form with the details of intervention and the start and end date so I can get compensated for the hours I was online.

The "You build it, you own it" medal has another side that says "You break it, you fix it", meaning that we should work on stability and technical debts and include technical plans on the roadmap to prevent incidents. If the incident happens, the person or the team owning it are accountable to fix the situation, even if it's outside their usual working hours.