DevOps literature expounds on the fact that “DevOps is a Culture”. The C.A.L.M.S. acronym (Culture, Automation, Lean, Metrics, Sharing) reminds us that the organizational attributes that contribute to successful DevOps are fundamental and shared across teams. The message is clear: DevOps is not the job of one person or a group of people, and it can’t succeed unless the whole org is involved and on-board. There are no DevOps Engineers! Everyone is a DevOps Engineer!

And yet. Who builds and maintains the lightning-fast, highly available deployment pipeline? Who performs the upgrades of the CI server? Who gets paged when the disk space on the binary repo fills up? If this is left to communal ownership, eventually internal tools become a Howl’s-moving-castle of poorly optimized, unstable and insecure utilities held together with duct tape and baling wire. These business-critical assets deserve better. Subject matter expertise in CI/CD best practice and current technologies is necessary for making informed and intelligent design decisions about these tools. Changes and improvements to these tools need to be based on a guiding vision that is aligned with the organization’s mission. They need a product owner. They need dedicated developers whose job it is to “make it go”. So, we hire DevOps Engineers.

As Manager of Dev Enablement, I struggle with this duality daily. How can I most effectively generate urgency outside my team around organizational change a la DevOps, while simultaneously providing strong vision and product guidance to my team that works on CI/CD and other internal tooling? Given that my team is tiny, where can we put our lever and fulcrum to most effectively uplift the entire org? I will share my thoughts, experiences and learnings on this topic.

Manager of Development Enablement

I am passionate about inspiring and supporting young women to pursue careers in STEM. My background is in Applied Mathematics, and yet my acting and theatre