For the sake of simplicity, let's ignore the idea of DevOps for a minute, and, to use an analogy, talk about Development and Operations as two partners in a marriage. Like all marriages, this one started happily.

Development has a special set of skills that it brings to the relationship. They are often on the front line of requests from other teams, like Product and maybe Sales and Marketing. They might spend hours perfecting a design implementation or weeks on a major feature overhaul requested by Sales. In a sense, they thrive in change.

Operations, on the other hand, is focused on the very real and practical need to provide reliability and predictability. They focus on long-term needs and, in many ways, safeguard the reputation of the business. They are stewards of stability and bear the burden of responsibility when things go wrong. Which, in a sense, is why sometimes this marriage goes a little sour.

Marital Strife

Development's very real need to implement change can often run against the grain of Operations equally very real need to promote stasis. To step outside of the analogy, this can lead to very real feelings of discomfort for the humans behind these teams.

One of the common points of conflict in marriage arises when partners have different definitions of success. Perhaps one partner feels loved with physical affection, while another prefers to hear words of affirmation. This difference in understanding of success can create division in partners, just as it can create division between teams.

If Operations is defining success in terms of metrics like uptime, error rate, and end-user performance, while Development defines it with product velocity, time-to-resolution, and bug backlog, real differences can emerge in expectations between teams.

Relationships can also suffer from imbalances. For example, maybe one partner feels like they're contributing a lot to the family's finances, while another partner is making a big contribution by maintaining the household. In healthy relationships, this works great as both partners bring complimentary skills to each other.

Sometimes, though, these differing areas of responsibility may not be appreciated. If one partner feels that they're solely contributing to the finances and the other is frivelously wasting money, conflict emerges. This type of conflict is common between Development and Operations teams. Poorly-tested changes by Development leading to 3:00am pages for Ops is an imbalance in responsibility. Likewise, slowly provisioned infrastructure resources, delaying Development ship dates and impacting velocity is an imbalance in responsibility.

Marital Counseling

But these differences can be overcome using the same conflict resolution techniques found in marital counseling. While it may not be necessary to sit your Dev and Ops teams down and explore feelings, it is necessary to come together to commonly define success and to identify and remediate imbalances in responsibility. These conversations should happen early and often between these two partner teams.

Another important approach is to redefine each team's ownership of responsibilities. Is one team shouldering all the pager duty load? Maybe it should be shared. After all, "move fast and break stuff," sounds a lot better at two in the afternoon, than it does at two in the morning. Companies like PagerDuty and VictorOps have mature alerting offerings which allow for intelligent pager routing based on what breaks. Cluster went down? Page Ops. Service failed? Page Development.

Of course, intelligent paging requires intelligent metric collection, which brings us to the second critical piece of counseling: shared understanding. Operational success and Developmental success should, ideally, share common success metrics. One way to approach this is with internal Service Level Agreements (SLAs). Say, for example, that Operations commits to provisioning new infrastructure within 24 working hours (three typical days) on request from Development. Development, in turn, commits to providing Operations with 40 working hours (or one typical week) advance notice of requests. This method provides two buffer days to accommodate any unexpected exceptions to the plan, while allowing for both teams to get what they need and for both teams to be successful.

Marital Bliss

Like all happy marriages, this approach takes work and communication. The result, two happy teams each contributing to shared success, is worth the effort. Want to get this process started in your organization? A great starting point is to offer an SLA to another team. They just might appreciate it enough to reciprocate.