3 ms·

> meanwhile, some developers complain that they didn't sign up to "be on call", despite that they are only being tasked with such for their own team's code If

by serge2k 11y ago

> meanwhile, some developers complain that they didn't sign up to "be on call", despite that they are only being tasked with such for their own team's code If they didn't then how is that not a legitimate complaint? If I take a job with the knowledge that oncall is required then it's fine. If I take a job and 6 months later they hand me a pager and say starting now you're oncall one week a month I'm going to get upset.

thwarted 11y ago
It is a legit complaint, but I lacked both the influence and the authority to get members of other teams to step up, and honestly that wasn't my job (not being their manager). And when there were outages operations had to be there to resolve issues because other teams had, for example, not formalized their on-call rotation. And yet the service needs to remain running and available. This is why I said it has to be the goal of the entire organization. If 6 months in you are tasked with being involved with deployment and live maintenance of your code, you're welcome to leave the company because it's going in a direction you don't agree with. Don't be shitting on the operations team because they didn't implement some VP-read-in-a-book version of DevOps. You know, there's a lot of talk about how "lack of culture fit" isn't a legit reason to reject candidates. While it is often used as a catchall rejection, there are things such as fitting into the organization's processes and having views that are compatible with the rest of the team that legitimately fall under the "culture fit" evaluation umbrella. If you're joining a team that has successfully done waterfall for a long time and doesn't have the problems that are traditionally associated with the things that agile can fix, sorry, you're not going to fit in and you'll most likely get resistance to change. If you're used to throwing code over the wall to operations to deploy and you're joining a team that takes a more distributed view of responsibility, you're not going to fit in either.

by serge2k 11y ago

thwarted 11y ago

It is a legit complaint, but I lacked both the influence and the authority to get members of other teams to step up, and honestly that wasn't my job (not being their manager). And when there were outages operations had to be there to resolve issues because other teams had, for example, not formalized their on-call rotation. And yet the service needs to remain running and available. This is why I said it has to be the goal of the entire organization. If 6 months in you are tasked with being involved with deployment and live maintenance of your code, you're welcome to leave the company because it's going in a direction you don't agree with. Don't be shitting on the operations team because they didn't implement some VP-read-in-a-book version of DevOps. You know, there's a lot of talk about how "lack of culture fit" isn't a legit reason to reject candidates. While it is often used as a catchall rejection, there are things such as fitting into the organization's processes and having views that are compatible with the rest of the team that legitimately fall under the "culture fit" evaluation umbrella. If you're joining a team that has successfully done waterfall for a long time and doesn't have the problems that are traditionally associated with the things that agile can fix, sorry, you're not going to fit in and you'll most likely get resistance to change. If you're used to throwing code over the wall to operations to deploy and you're joining a team that takes a more distributed view of responsibility, you're not going to fit in either.