Originally posted on the Puppet blog, and republished here with Puppet's permission.\n\nYou want to create a much closer working relationship between your IT operations team and the software development team. How do you do it? Here are a few highlights from Puppet\u2019s ebook, Get Started with DevOps: A Guide for IT Managers around fostering collaboration between teams and easing the transition.\n\nCollaboration over contract negotiation\nOne of the tenets of the agile manifesto is "customer collaboration over contract negotiation." This also applies to the relationship between development and operations teams. Devote some time to helping the dev team; for example, instead of holding meetings to set some minimum performance measures, pair with the dev team to help them measure, and then improve, application performance. Pairing is a great way of starting collaboration across teams \u2014 and the dev team will likely be happy for the help.\n\nSecurity is a great icebreaker\nOps teams have a healthy fear of real-world users and a good eye for security issues\u2014for good reason. Developers are interested in security, but don't always have expertise in it. That's why security can be such a good place to start. Your ops team can offer internal training sessions on security, and invite developers into threat briefings. Show devs the monitoring data around malware or DOS attacks. By giving people common information, you'll help people appreciate each other's expertise and build relationships between the teams.\n\nBuilding self-service platforms\nIt\u2019s increasingly common for operations teams to be internal service providers. Rather than having your ops team deploy everything, develop a standard way for developer to deploy their own applications. Rather than the ops team being the only people who have access to production monitoring, the team can instead maintain the monitoring system and provide self-service access and training to devs.\n\nThis won't happen overnight. Start by identifying largely repetitive work that is ripe for standardization, and then design a service model around that activity. Repeat for other common activities. The shift to self-service will fundamentally change the relationship between Ops and Dev, from operators slowing developers down to operators empowering developers.\n\nYou built it, you run it\nThe best people to support a complex application are the people who built it. Help development monitor and support their applications. Once the development team knows they will be directly responsible for any problems in production, they are much more likely to make sure the software is operable, stable and resilient to failure.\n\nThis doesn\u2019t mean traditional operations skills aren\u2019t needed. It might mean the team structures change, and that the organization moves towards cross-functional teams of developers and operators. Ops might also become a smaller services team for the entire organization, setting standards and offering their expertise and advice when needed.\n\nManaging change\nThere are a few things you can do to help both your own operations team and the development team transition to the new way of doing things. Here are a few ideas:\n\n\n\nDevelopers often underestimate \u2014 or simply aren't aware of \u2014 the parts of operations and service management that aren't strictly about code deployment. The ops team can train developers on things like capacity planning, incident management or auditing requirements, preferably through pairing. Most people learn better by working with someone, and pairing is a great way to develop greater empathy between teams.\n\n\n\nInvolve the development team in designing shared services \u2014 after all, what your operations team members want may not align with what the developers feel they need. Start by clearly defining user needs, and work out what\u2019s possible in the short term and medium term. Involving both teams should lead to a better service and a better understanding of the underlying problems and tradeoffs.\n\n\n\nInclude developers in on-call rotations. The main benefit here is in aligning incentives; it's a lot harder to consider actually shipping software that has performance or stability problems if you know you're going to be called when things break.\n\n\n\n\nThe above are just a few practical ideas you'll find in Get Started with DevOps: A Guide for IT Managers. Read it for more help in winning over your own operations team, the development team and executives to the DevOps way of working.