This is a guest post from John Custy– President of JPC Group and a 35-year veteran of the IT industry.

When asked what problem DevOps aims to solve, Service Operations Lead, Patrick Hill, responded,

“It’s the problem where no one’s aligned and no one gives a sh*t about what the other team is up to.”

Or in Forrester’s words, “within these narrow purviews, each regards the other as a barrier to success, and neither is rewarded for achieving the customer experiences that drive business results.”

This is how DevOps originated: to address the conflict between development and operations teams.

Development teams want to launch features fast and frequently while IT Ops wants to maintain infrastructure stability and availability – which means as little changes as possible. Customers want both.

These two practices manifest themselves in many ways:

  • Reliability: When there are new releases, developers chuck code over the wall for the operations team to put into production. Lack of communication and intimate knowledge of the code makes it difficult to ensure reliability in production.
  • Quality: IT receives user-reported incidents every day. These incidents are typically isolated from development in a completely different system. When incidents aren’t linked to a development backlog, they aren’t considered. Lack of user feedback means product quality suffers.
  • Support: When escalations happen, they can get lost in the transfer from IT and development. This makes it hard to communicate what got fixed and when, resulting in dissatisfied users.

DevOps is a movement that advocates a collaborative working relationship between Development and IT Operations, where historically they have been separated. In Patrick Debois’ words, “DevOps is not about a technology, DevOps is about a business problem.”

Here are the three main DevOps principles (from The DevOps Cookbook) and how to apply them to your IT team:

The first way: systems thinking

“The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department. DevOps transcends departments and showcases the overall value to the customer.” – Gene Kim

IT pro-tip #1

Developers are often isolated from the rest of IT in larger organizations. Even though they’re part of the same department, lack of collaboration can impact how teams work without so much of a reason as people sit in different parts of the building or don’t talk at lunch. However, they often need to work together.

Not only should developers assign resources for escalation, but also they should also support the SLA with the customer. The SLA makes them accountable for impact to business productivity, aligning them with IT.


When you have a collaborative culture – results happen.

At Atlassian, employees submit their issues to the company’s Jira Service Desk customer portal. The Workplace Productivity team will work through that queue to resolve what they can and what they can’t.

“If they identify any issues that affect more than just one user, they will forward the incident to Workplace Engineering for us to investigate,” explains Joe Flowers, Senior Systems Engineer at Atlassian. “If it’s an issue that has to do with the network, we will collaborate with the Network Engineering team to quickly resolve the problem. All of this happens in Jira and Jira Service Desk. We’re held accountable by the SLA.”

The second way: feedback loops

“The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made,” – Gene Kim

feedback-loops-jira-service-desk-devopsWhen you improve feedback between development and IT, stakeholders understand their impact toward the overall goal. Clarity between both teams erases the red tape. When both teams work transparently, missteps and communication breakdowns are a thing of the past.

IT pro-tip #2

Beyond automated unit tests or customer interviews, feedback exists right before our eyes: the service desk. By analyzing incident data, you can understand what’s working and what’s not.

Workplace Productivity and Workplace Engineering are sister teams at Atlassian.


One handles the internal service desk while the other builds and improves applications. The two teams often collaborate through meetings, Jira Service Desk tickets and talking at their desks (they sit right next to one another).

One example of a support to development feedback loop is when staff started reporting login issues. There were too many usernames and passwords to remember for all of Atlassian’s systems.

These reports piled up, and it became apparent: they had to do something about it. With Workplace Productivity showing data from their service desk, this became a project for Workplace Engineering. Eventually, a single username and password for all employees was rolled out, and there are measurably fewer login requests. This was how user feedback directly impacted business productivity as a result of collaboration.

The third way: continual experimentation and learning

“Creating a culture that fosters at two things: continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery,” – Gene Kim

This might be allocating time for experiments or creating rituals that reward your team for risk-taking and success.


IT pro-tip #3

Run small experiments at a regular cadence. Test a hypothesis and measure the results. This can be an outage “fire drill” where you practice the ways in which your team deals with a major problem.

Netflix does this with “Chaos Monkey“, a service that runs in Amazon Web Services that terminates instances (virtual machines).

“Over the last year Chaos Monkey has terminated over 65,000 instances running in our production and testing environments. Most of the time nobody notices, but we continue to find surprises caused by Chaos Monkey which allows us to isolate and resolve them so they don’t happen again.”

What’s your experience? For those of you who have introduced DevOps to your IT team, what worked and what didn’t?

This is part 1 of a 6-part blog series by John Custy.

If you’re interested in more DevOps, get the latest ebook by ITSM expert John Custy. He’ll show you how to bring DevOps principles into your IT support team with actionable tips.

Get the ebook

3 DevOps principles to apply to your IT team