How to Kill Your DevOps Initiative

DevOps is hot. Everyone wants it. Continuous delivery is not just for the cool kids in the loft office anymore. Enterprises that have a long history of ‘hardware,' like Target, ING and Cengage Learning, are transforming into software companies. They need to be able to experiment in the market with shorter lead times. A potent brew of collaboration and automation is required.

A quick note: Startups, you are not doing DevOps by default. Just because you sit together does not mean you don’t also have to put in the difficult work of creating and maintaining lean delivery cycles. I’ve worked for large and small organizations, and the notion that “X only works in startups,” or increasingly common, “X only works in enterprises,” is disingenuous. This is the definition of a red herring.

import random

X = random.choice([
    'continuous delivery',
    'feature flags',
    'blameless postmortems',
    'config management',  # seriously
    'and so on'
])

not_for_us(X)

Okay, back to the enterprise. A common approach to adopting DevOps in large organizations is to create a DevOps initiative, a tightly-scoped project meant to achieve quick success and build goodwill throughout the organization. Sharing this success is a trigger, encouraging other teams to get involved.

Often this initiative takes the form of a DevOps or 'skunkworks’ team, a cross-functional group made up of hand-selected high-performers from other teams. This usually works great. After an awkward courtship phase, the team members learn to rely on each other and you’ve got that new project out the door in much less time than you estimated. It’s in production and customers are submitting feature requests.

Here’s the rub. You now have to determine why that team was so successful. What worked, what didn’t and what is transferrable to other teams? You can measure a lot of things in the SDLC, but they never add up to the whole picture. Duplicating this success for other projects is difficult, and requires leaders that understand, and can share, the vision of the future for your organization. When this vision is unclear, no one wants to break the DevOps/skunkworks team up. There is something magical happening there that you don’t want to mess up. This is how you kill your DevOps initiative.

You kill your DevOps initiative by incentivizing an initial group of engineers to be creative and try new things, and then pull the rug out from under them by assigning them the task of maintaining their creation indefinitely. These engineers want to move onto innovating in other areas of your organization. You have engineers that are more maintenance-minded. That is perfectly fine; place them in maintenance roles.

This isn’t just a thought exercise. I’ve been on a skunkworks team that followed this pattern. I quit after a couple months of maintenance mode with no end in sight. I personally know many engineers that also moved on to new positions in the same situation. We’re willing to put up with it if there is an end in sight. Engineers aren’t work units to be shuffled around. They will vote with their feet.

Recap. How do you kill your DevOps initiative?