Patrick Debois: Size Doesn’t Matter When It Comes to DevOps

There are few people more knowledgeable about the meaning and importance of the DevOps moment than Patrick Debois. He practically invented it, and he organized the very first Devops Days event in the development dark ages of 2009.

So, naturally, we thought of Patrick when we decided to ask some thought leaders to help us define the term and talk about where the movement is headed. Here are some excerpts from our recent interview:

What is the difference between DevOps for startups and DevOps for enterprises with legacy technology?

The irony is that people in startups often do already share stuff/collaborate, as this is easier, although they might still think in terms of their expertise and don’t spend enough sharing knowledge. I think “truck factor” for them is often high.

Do you think there’s a nexus between the size of an organization and the successful implementation of DevOps?

It is less on size, more on the culture that is already there. If you want to learn and improve, DevOps feels natural. Even if you’re big, you can have that culture of trial/error [to] improve. Unfortunately, in the bigger companies the risks go higher and this brings a big inertia, though they would benefit from doing smaller things more often. But the layers of management need to adjust to the speed of feedback.

What are the biggest management obstacles in implementing or encouraging a DevOps culture?

The question of, ‘Who is the boss now?’ [and] ideas like ‘We can’t fail,’ or ‘Resources can’t be idle.’

Who or what in organizations is the primary or most common obstacle?

The people who have a harder time dealing with change or, specifically, the speed of change.

Do you think it’s possible for large organizations to disassemble silos to realize the benefits of DevOps?

Sure. Again, it might take longer as the idea/energy needs to spread. You need to apply the same change-success principles to make it successful, like having management buy-in. But also at the lower level, you have to start with small successes and having sponsors, etc.

If you have seen such a case, can you give an example of where and how that was accomplished?

Alas, I can’t say from the inside, but I’d say the Nokia folks have done a good job. (Editor’s note: Here’s a good summary of the Nokia experience.]

Who is responsible for DevOps?

Easy: Everybody. But [you need] someone with a specific focus, like a referee. He can keep people in line with a vision.

Is the CIO in the best position to drive DevOps change?

CIO support is great, but not sufficient. You need buy-in from all management layers and tech people.

Will DevOps last, or is this a fad?

Like all memes, it will last. Probably most things around infrastructure as code will stick, and the monitoring. Like ITIL, DevOps will get new names to drive new energy in the industry.

Is there too much hype around this movement?

There is a considerable amount of tool vendor/rebranding. I have yet to see a company that goes big on the #DevOps cultural side. That would be important, but hopefully it doesn’t become a vendor-driven new idea.

Do you think there’s a danger of DevOps being unfairly dismissed as an idea because of the hype?

The beauty is in the eye of the beholder. People who dismiss hype because it’s  hype, well, that’s not too smart.

What is the proper role of technology tools in enacting a DevOps culture?

A supportive role, but also as a change enabler. A new tool can bring a new habit or a new perspective, like people changed their view after they actually used the cloud.

How does a company know if they are doing DevOps right?

I would say they know it when the pace of innovation and time to market fits their expectations. Whether that’s one deploy a month or one every hour. As long as you use the feedback to improve every time.

This post originally appeared on servicevirtualization.com.