Preface
Imagine this scenario: a small web company is starting to run into problems—its website is straining and experiencing regular failures under unprecedented growth. Employees are increasingly unhappy with the number of hours required to maintain services while also trying to implement and deploy new features. Language and time zone barriers are contributing to friction between globally distributed teams. A culture of blame has grown around the tense reactions during site outages, resulting in increased suspicion and decreased transparency between teams.
Given these problems, the organization decides that devops sounds like a good solution. Management hires several new people to join their new devops team. The devops team has on-call responsibilities, where the existing operations team can call them to escalate issues that they don’t know how to address. The devops team members have more industry experience than the people on the ops team, so they are generally better equipped to handle production issues. Without the time or opportunity to learn new skills, however, the operations staff keeps escalating the same issues over and over again.
The devops team gets tired of acting as go-between for both the development and operations teams. Rather than defusing the culture of blame, management’s “solution” has produced twice as much miscommunication, because none of the teams are privy to the planning processes, emails, chat messages, or even bug trackers of the other teams.