It’s 6.00 AM. I’m sitting on a high-speed train heading to Madrid. Today I’m going to deliver a talk about DevOps at Google.

DevOps is the new black. It’s the new trendy buzzword among computer geeks.
You know, IT is that way: we need to invent a new word every year or two to keep the hype up. DevOps is now having momentum, like Agile had a while ago. But, seriously, how many people really understand what agile and DevOps are?
Or, even more important, how many people actually know what it isn’t?

Too often, buzzwords in the tech industry lose their authentic meaning, becoming just buzzwords with nothing behind it. So let’s try to put some meaning around the DevOps buzz.

We can summarize DevOps with the well-known DevOps formula“CALMS”, which stands for:

Culture + Automation + Lean + Metrics + Share.

In my humble opinion, Culture is the most important element here. If you have tools (automation) but you don’t have the culture, nothing important will change and the returns you may expect will be between something small and nothing.

So to start talking about culture, let’s navigate through the top 3 myths I have observed more often across tens of customers and development teams.

Myth #1:
“DevOps department” or “The DevOps guy”

There are no such things. If we have to choose one and only one main point to explain what DevOps is, I would say it is about breaking silos. DevOps applies only to organizations, as it implies communication between all the stakeholders involved in providing a service. It means from business people defining what they want, to developers, people writing documentation, tests and quality assurance, deployment and, of course, continuous operation. It’s about having feedback loops that goes both left to right (typical cycle) and right to left; it’s about amplifying the feedback and shortening the cycle of these feedback loops, between all the agents; it’s about all the agents involved having full understanding of the whole system, not only of a part of the system (holistic approach versus specialized silos). So talking about a DevOps department makes no sense, as it’s a process that crosses many traditional departments and that aims to break the walls between them. It’s more about breaking departments than about creating departments.

Talking about a DevOps guy or a DevOps manager is a non-sense as well, as DevOps is not a task of an individual neither the task of a team. It’s a task involving the whole organization. It’s just like providing the service your company provides: it’s the outcome of the work of the whole organization, engaging all the processes of the company, to deliver the value produced by your key activities to your customers through a set of channels, etc.

DevOps involves Software development, product design, Quality Assurance, and continuous operations, including customer support, billing, etc. You need all the feedback. Everybody needs to understand how the system works. It’s an organization-wide process rather than a department’s or an individual’s job. So it’s about a DevOps organization.

Myth #2:
DevOps = DIY

(Or “DevOps is a guy doing everything from design to continuous operations, including development, QA and deployment”)

Many times I’ve heard CTO’s, Development managers, and similar roles saying something like: “we don’t use external companies to help us, we’re following a devops approach”.
Once, the CTO of an online company told me: “we follow a DevOps approach, which means we do everything ourselves. We created even our most basic software like email or accountancy”.

DevOps is not about reinventing the wheel in any way. DevOps is about being extremely efficient.

And what does efficient means here? Efficient means serving your customers in the best possible way, all the time, everyday, as the environment keeps changing. So my question in these situations is: “how many time do you spend doing tasks that can be done faster, and probably better (as they are not your core competency), instead of finding ways to better serve your users and customers?”.

Can you imagine a car manufacturer (remember that DevOps comes from Lean, and Lean comes from Toyota) trying to do everything by itself, including batteries, steel, aluminum, rubber, tires, engine oil, etc.? I don’t know, but I don’t even think that Google, which manufactures their own servers, manufactures their own copper cables, steel or aluminum enclosures, all their own CPU’s, etc.

So the key point here is not to Do-It-Yourself. It’s not efficient at all! The key point is to don’t break the feedback loops when you decide to outsource part of the service.It means that you should wisely select the partners that will be your companion along the journey.If your partners aren’t qualified enough, you will probably have poor quality feedback. If your partners are highly skilled but the communication between you and them isn’t good enough, you may have no feedback at all. If you fail to communicate properly to your partners, they will have a much more difficult position to have a holistic view of the system, so feedback will be damaged too. Which of them is worse will depend on each specific context. But in the end of the day, all of these situations are really bad.

Myth #3:
DevOps is black magic that you can buy and have immediate super-powers

Maybe we’ll talk in a future post (or not) about the dos-and-donts of trying to DevOps. However, DevOps is not black magic. There’s no secret sauce. So don’t expect to read a manual or pay few journeys of consultancy and immediately discover the Philosopher’s stone.

DevOps is, more than any other thing, a cultural shift.

And you know, changing the culture within an organization is not an easy neither fast task. It requires effort, authentic willingness, perseverance, failures, and a lot of time. A lot.

And of course, if you want to change the culture of an organization, there are some things that certainly won’t work at all, like the big bang, which means trying to change everything at once and immediately, and prohibitions; prohibitions and hard rules may seem to work for a short period of time, but you will not change the culture, just force some behavior through greater political power and fear. Also, tools alone without cultural shift, as we said before, won’t produce the results you may expect from a DevOps-oriented organization. Not in the long run.

So don’t expect to buy something or pay somebody and become, magically, the most super-efficient DevOps-oriented organization in the world.

Expect to start a journey. A long journey full of traps and risks that will guide your team through oceans of learning and will make your organization a bit better every day. And wish that this journey never ends.