Speaking simplistically, organizations tend to move towards DevOps in either of two ways:

  1. Some have been evolving towards DevOps for awhile, often without intentionally planning it from the outset, because treating infrastructure like product code was a natural progression toward faster time-to-market and greater efficiency.
  2. Others are looking to hire a “DevOps engineer” to transform their organization and get them on track.

If you’re in the latter camp-trying to find that white knight who’s going to ride into town with a satchel full of open source tools to change your entrenched waterfall processes and “make us DevOps”-your efforts are doomed.

DevOps requires a major organizational mindset shift. It’s about moving faster and failing faster without getting sloppy, and everyone needs to participate. Hiring someone with experience in an organization that has successfully put together its DevOps puzzle, and letting them put their favorite tools in place, will not result in DevOps.

Mindsets and processes also have to change, and it takes more than a point person in an engineering position to make that happen. For example, a team that migrates its infrastructure whole-hog from a traditional datacenter environment with traditional development and operations roles to a public cloud might still end up with 1,000 manually configured virtual servers that they’re nurturing as if they lived in a rack down the hall.

Yet at the same time they could still be moving faster and saving money and making progress towards their DevOps goals. My point is that it’s next to impossible to make the mindset shift into DevOps all at once.

People get used to how they like to do things. Even if they’re not super-happy in a role, they might resist changing how that role functions. Better to foster the transformation in clearly articulable, supportive steps that address your actual pain points.

Another problem with the DevOps white knight plan is that white knights with highly specific, in-demand skills are expensive and hard to find. Many hiring managers I talk to are unable to fill those uber DevOps roles after months of trying.

DevOps can come together more organically when teams focus on skills more than roles. You can roll your own DevOps by helping sysadmin types build development skills (while learning more about developer needs) and helping developers become more operations-aware.

One idea is to let developers sit in with the operations team for a week or two, and vice versa. Get everybody talking and moving in the same direction, and let them self-select into roles over time based on their inclination to be more development- or operations-focused.

What generally happens if you do successfully get a white knight to rescue your DevOps damsel in distress? Here’s what I typically see: He or she comes in, tosses out your partially implemented configuration management toolset and starts implementing something else; e.g., Chef. Nobody learns the new automation but him, so things are still sloppy.

Then he leaves. So you hire someone else. She chucks Chef and re-orchestrates everything in Salt. So now you have some Chef and some Salt, and your configuration management is still sloppy and often ad hoc. Then she leaves. Meanwhile, you decide that things will get better if you switch to Puppet…