So you’re on a DevOps team that is siloed from both Dev and Ops? And the Dev organization has no interest in continuing their DevOps transformation? A good DevOps Engineer is always pushing for improvements so stay tuned for tips on How To DevOps When Dev Doesn’t Want To.

Many companies start their DevOps journey by creating ‘a DevOps team’ but the transformation stalls there. They want all the benefits of CI/CD automation without putting in the work of a total DevOps culture transformation. So what do you do when this DevOps team wants to really drive DevOps change but Dev isn’t fully invested in the idea? We will discuss techniques for moving DevOps transformation forward even if all the parties are not fully participating in the transformation.

Tips will include:

• Build a coalition of DevOps champions from across all the silos (dev, QA, Release Mgmt, Product Owners, Ops, etc.). While the senior management of any one silo may not be pushing for a DevOps transformation there are often grass roots efforts that can be enhanced.
• Don’t call it DevOps … but keep making changes. Suggesting a full re-org to follow a Spotify model (tribes, squads) or suggesting that everyone become an SRE (Google) may not get much traction. But other models like TBM (Technology Business Management) or SAFe can be used to frame the discussion of cross-functional teams without ever using DevOps terminology.
• Write it down. It’s amazing how many process changes dev will accept if they’re written down, especially if no counter process had been documented previously. This documentation often comes in the form of ‘acceptance criteria’ which define pre-requisites and standards that dev must meet before submitting new work to the DevOps team. Writing it down helps shift standardization to the dev side so DevOps team doesn’t have code around dev inconsistencies.
• Blur the line between dev and ops with ‘self-help’ tooling. Often DevOps teams receive stories with requirements from dev to update a build, a cookbook, or a database. By making it easier for Dev to submit a PR for the update themselves and having DevOps team act as reviewers (instead of initiators) we can reduce handoffs and increase collaboration while shifting the line of ownership towards Dev.
• Take baby steps. If the whole org is not bought into the idea of a DevOps transformation the process will take longer. That’s OK. It may be necessary to take baby steps to prove the value of DevOps culture in small areas before they’re willing to accept a full transformation.
• Influence outside your lane … but be careful. It’s likely that upper management is skeptical of giving up their silo control and may see DevOps as intruding on their domain. By combining the tips above there are ways to make incremental changes without threatening the manager who wants to protect their turf.