"You do not have to be Albert Einstein to handle your IT assignments 'On Time' (i.e. To Schedule), 'At Cost' (i.e. To Budget) and 'To Specifications' (i.e. To Scope)"
Yaacov (Jack) Bar-Tor
Information Technology
YBT Services Pty Ltd
Incentive & Responsibility Alignmemnt
One of the early controversial aspects of what became DevOps was the assertion that Engineering should be doing on-call rotations. In fact, this idea was presented in a way that made it sound like your developers would want to be on call if they were truly dedicated to building the best possible product, because they were the ones responsible for the code.
I don’t remember now who first articulated this point; my personal DevOps epoch begins with John Allspaw and Paul Hammond’s Flickr talk at Velocity 2009, and they may have mentioned it. Regardless, the cultural characteristic here is empowerment. The people who are empowered to directly make an improvement are the ones who are alerted to the defect.
Likewise, your team is incentivized around your core goal: creating an awesome product for your customers, whatever that product happens to be. Development isn’t rewarded for writing lots of code. Operations isn’t punished when all that code doesn’t run as expected in production. The team is rewarded when the product is awesome, and shares in the improvement process when the product could be more awesome.
