Secrets to Collaboration in DevOps

In IT and engineering departments, the notion of teamwork hasn’t been a priority until recently. People were hired based on their in-depth knowledge of a particular technology category, such as networks or operating systems. There wasn’t much need for someone in networking to talk to his server colleagues, unless the whole team was going out for a beer. Those were the happy days of ITIL, in which processes and procedures for maintaining systems and solving problems were linear and preprogrammed. With a solid configuration management database on hand, the world of IT management was a well-oiled (although sometimes slow) machine.

This approach was okay when companies were only relying upon a few large application suites. But now, of course, this arrangement has been turned upside down. With hundreds of applications running the business, and those applications dependent upon hundreds or thousands of services and components, ITIL falls short. People working in silos can no longer effectively manage performance and resolve issues with this level of infrastructure complexity. Companies nor their customers don’t have the patience to wait hours for a website to resume service or a critical application to function properly again. These disruptions cost too much money to fix and can darken revenues and customer relationships.

Enter DevOps: the new way to deal with rapid change and complexity through ongoing releases and frequent adaptations to the environment. In a 2013 survey of IT decision-makers by research firm Vanson Bourne, the top reasons for adopting DevOps were the need for simultaneous deployment across different platforms, and business pressures to release apps more quickly to meet customer demand and to improve the customer experience. A majority of the 1300 survey participants, 66%, said they either have a DevOps strategy or are planning to implement one.

At the core, DevOps success relies heavily on collaboration between developers and IT operations staff. Only through the daily, open sharing of knowledge and best practices can a company solve problems and optimize applications efficiently in the DevOps fashion. To complicate matters, employees are living and working all over the place today. Bringing their insights together when it matters requires not merely the right tools, but the right culture. Here are some ideas for fostering collaboration in DevOps environments.

1. Get rid of departmental silos and rigid processes. With a culture focused on ITIL, problems eventually get resolved—but often after a few hours or even days of running a question through the ranks;  by then the damage is done. This is no longer acceptable when employees and customers expect always on, always speedy service. After all, that’s the standard they readily achieve from their personal applications and devices. If your organization relies upon modern, highly scalable and visible applications, you need to break down internal barriers without delay. Forget about DevOps for a moment, and determine how roles might need to shift or rigid processes (such as approval chains for changes) may need to dissolve for the sake of fixing a problem right now. Empowering individuals to make changes immediately when conditions justify it is how technology organizations must operate today.

2. Encourage discussion: Do employees only talk in the break room? If so, start scheduling daily standup meetings for the purpose of sharing status, timelines and exploring ideas. Finding the right time to accommodate people in different time zones might be tricky; in large, dispersed organizations, holding two daily meetings may be required.

3. Eliminate hierarchies: Even in the flattest of organizations, informal hierarchies persist. With DevOps, however, it matters little if you are “the smartest person in the room” or have been with the organization the longest. Maintaining organizational hierarchies too often works against the goal of sharing information across the organization to better IT operations and application performance. Managers should work hard to encourage open sharing and the notion of equality among team members. Reward employees for their teamwork efforts and for showing mutual respect. Instill the notion that everyone is responsible for delivering excellent service and for resolving problems, not guarding turf. While this is an idealistic philosophy that’s hard to carry through on a daily basis, working toward this goal will in time grow a collaborative culture.

4. Develop a business orientation:  In a DevOps culture, understanding the needs of the business is the highest priority. In fact, respondents to the Vanson Bourne survey said that the top three skills needed for DevOps are knowledge of business, priorities, strategies, or metrics (47%); knowledge of current business processes (42%); and communication skills (32%). Keep these qualities in mind when hiring new employees and when promoting those from within to senior roles. Create opportunities in which technical staff can interface with business leads to gain that critical business perspective.

5. Set the tone at the top: As in most companies, the people in charge maintain a heavy influence on corporate culture. So, what if your CEO places a higher value on individual contributions than teamwork? It may feel like fighting an uphill battle, yet the CTO of a CIO or other person in charge may need to spearhead an education initiative to help higher-ups strike a balance. That can result in small yet powerful changes, such as instituting new employee incentives and more frequent performance review programs that align with DevOps goals.

6. Sometimes, outsiders are required: DevOps is still a fairly new practice, and companies may not have in-house expertise to develop a new culture around it. Fortunately, there are an increasing number of outside coaches that can help organizations jumpstart new ways to organize and work. These experts can also objectively assess progress and help team members navigate difficult transitions or high-stakes projects. If such a coach can help your team get up to speed 50% faster on new collaborative practices, it will be time and money well spent as the business will see results faster too.

7. Attitude is everything: On the surface, it would seem that younger people, those highly coveted “Millenials”, will be the front runners in DevOps organizations. Yet don’t make assumptions. If an older employee with decades of experience in operations and across different industries is willing and open to change, he or she could be the most valuable person on your team.

8. Get rid of the dinosaur tools. Traditional APM and IT monitoring tools from enterprise software vendors may not have the right interface nor feature set to help DevOps teams keep up with cloud and hybrid infrastructures. Whatever tools you select, make sure they incorporate the real-time, collaborative elements embedded in today’s top consumer apps and social media websites. Think open forums, comment streams, “more like this” intelligence, messaging and the ability to upload videos and images that enhance a conversation. If the tools are fun, simple and allow people to get the information they need in one place, they’ll use them. If manual correlation of data and events is required using a clunky interface, they won’t.

What’s powerful about DevOps is that while it requires new attitudes, methods and skills, the end result is that people are working together toward a common goal. Better collaboration doesn’t just serve DevOps, but an organization at large. It could result in a new development approach that kills the competition, or an IT management best practice that saves the company hundreds of thousands of dollars a year. Collaboration is the quintessential soft business skill, yet with the right intent, it can bring hard results that move the business forward.

About the author  ⁄ Mark Rivington

Mark Rivington

Mark has over 37 years of experience in the IT industry. Forever the technologist he has played leading technical roles in a number of major Systems and Performance management software companies including Candle, BMC, Nimsoft and CA Technologies. His most recent position was as CTO of Nimsoft, an organization that he helped grow from an early start-up, through a highly successful acquisition by CA Technologies in 2010 and beyond towards full integration. Mark is highly adept at bridging the gap between technology and business value and is a regular public speaker at industry forums. Mark operates on a truly global basis having worked extensively in all major geographies throughout his career. At Boundary Mark will be responsible for ensuring that the solution consistently matches the market and customer requirements and continues to bring outstanding value to the customer.

  • Andi

    Mark, appreciate your thoughts on this topic. Valuable advice for DevOps newbs.

    However, it would have been appropriate to properly cite and credit the research you referenced. For your readers, the study is the ‘CA TechInsights Report: What Smart Businesses Know About DevOps’. It was commissioned by CA Technologies, and conducted by Vanson Bourne.

    The whole study is available at (reg req’d).

    Andi Mann
    CA Technologies.

  • JP


    While your advice seems logical, I believe it wreaks of academia and little real world experience. It would be fantastic if organizations could accomplish the items you outlined above, but I don’t see it as feasible in many organizations. Your recommendation to eliminate hierarchies and flatten the organization in a large multi-national business is seemingly naive and highly unlikely. These organizations thrive on command and control. Moreover, I don’t see that silos are the enemy. They do represent a challenge to frictionless communications, but they also serve a purpose. Hence, it would be more useful for us to help large IT shops to figure out how to communicate in light of this situation.

    I have just posted a piece on, which I am hoping will be available shortly, entitled “Services As A Communication Model for DevOps.” I believe it presents a more pragmatic view of adopting DevOps in large IT organizations.

  • Pingback: DevOps and Enterprises, it's a culture thing |