Hacker News Reader

Comment by KallDrexx | Hacker News Reader

Every policy that gets put in place has the possibility of influencing behavior of those involved.

If your organization pays extra for on-call work, that influences buggier code because you will get paid to fix or solve it later (even if it's not intentionally buggy).

You see this all the time with contract work and it's a huge issue with low bids that end up costing a lot more because of the sunk cost.

Edit In fact, you already have developers fighting this incentive at your organization. If developers are already writing buggy code hoping that it will be someone else's issue and not caring when it's their turn to be on call, imagine when they get paid extra to fix the bugs they introduced to begin with

View on HN

Instead of on call, have coverage.

Rotate through different employees and give them times when they are responsible for //being awake and ready to work on short notice//: IE this is a normal hourly wage with the bonus that you don't have to be at work.

For both the above and 'on call', you also charge the 'department' with the failure's root cause (as determined later) the penalty and pay out a bonus for those needed to respond to the incident.

Why not pay a flat rate for taking the on-call responsibility, regardless of actual work performed?

This works. We did this for developer on-call rotations (which was also a development opportunity for rising engineers). We also did this when I ran Ops.

It's not perfectly fair in the micro sense, but it's fair enough to not trip most people's frustration meter and it's very easy to administer.

The way it used to work in the organisation I used to be part of (generally a good bunch) was that there was a flat-rate, plus an extra payment if we were required to do something.

Occasionally there was time in lieu given as well, if we were actually called and it was overnight/took a while.

Worked well, but as a general rule we were delivering a quality product, had good guys working for us and so we all felt responsible if something went wrong out of hours and would look at what happened and how we would prevent it going forward.

We also gave comp time for significant disruptions/outages, but that was mostly recognition of the practical reality that someone who normally worked days and unexpectedly worked 1-4 AM responding to the pager was going to be useless the next day anyway.

I specifically wanted to avoid variable pay, the associated timesheets tracking and approval processes, the HR and finance/payroll integration, and any temptation (beyond normal professional responsibility) to either decrease or increase the hours spent on a problem response. I'm sure it's different for different businesses, but I judged that paying on-call bonuses for weeks on-call quarterly was low enough finance integration effort and still gave the employees a sense that they were being paid some differential for being on-call.

Your last sentence is the key outcome to strive for and as long as you have decent leadership and culture, I think that's fairly easy to achieve in a small group. I don't need to be paid "extra" to do a little extra to help my team and company.

That's fine, but unless your on call scheduling is erratic and non-predictable then it's no different than pay that's included with your salary.

Like the article says, you really get the best results when the people responsible for the code is also responsible for issues that come up after hours. That means your team should be rotating out so that everyone feels ownership and responsibility for the deployment.

The Earth rotates and has people all over. We shouldn't have "after hours"

Placing folks around the globe doesn't really help with the weekend or holiday situation.

> Placing folks around the globe doesn't really help with the weekend or holiday situation.

Given that non-working "weekends" and "holidays" aren't global standards, it kind of can , though arrangements to simultaneously mitigate those situations and working hours situations may be more complex than ones intended to handle only one or the other problem.

Reply on news.ycombinator.com