This one gets articulated a lot as a way of explaining to people who don’t see (or don’t recognize that they see) the Dev vs. Ops pressures at work.
Fact is, most organizations compensate and incentivize these two teams in a way that is guaranteed to create conflict and a burning sense of antagonism. Basically, as the story goes, Dev is paid to make new stuff (i.e., make change happen) and Ops is paid to keep things stable (i.e., relatively unchanging).
I believe it was Jesse Robbins at a 2010 DevOps Days meeting who gave an eye-popping story about when he was the Ops (i.e., firefight) head at Amazon. Dev wanted to push into production code which Robbins thought from assessment that it was going to fail. But the decision goes up the food chain and reaches the VP (over both groups) and he sees the Wall-Street level need for the features in the code as the priority. He orders the release candidate into production, it goes into production, where it promptly falls over, hard.
But that’s not the end of the story. Here comes the kicker: year-end Dev group get performance bonuses because they met their feature delivery requirements, Ops group get no performance bonuses because they did not meet their availability requirements.
Yeah. That’s a body blow to cultural collaboration . . .
Kia Behnia: Part of this has nothing to do with technology. I hate to say that to the CTO of a company. It’s people process, and people process unfortunately still prevents good ideas and good technologies from taking shape.
If you look at the Ops team, historically in most organizations, they tended to be risk adverse and change adverse. Because they associate change with risk. Development teams, on the other hand, are always encouraged to focus on the next set of innovations, the next set of the releases.
So, when you don’t have a well-designed process and you don’t think about this, these two organizational models clash, and they clash at requirements time, they clash at deployment time, they clash when there’s an issue.
And a big promise of DevOps is to bring this speed of innovation that companies require with the control and governance and the safety net that they’re looking for, so that they can drive the car fast, but be able to slow down when they need to or break when they absolutely need to.