Interview series with DevOps influencers — Part 1

Collaboration or survival of the fittest: Who runs the DevOps world?

Gabriela Motroc

© Shutterstock / Tribalium

DevOps is all about collaboration but it’s not always easy to put theory into practice. After we’ve solved this dilemma, we need to get past the “What is DevOps?” question and answer “Where do we start?” instead. We invited nine DevOps influencers to clear things up for you. 

DevOps: Collaboration or survival of the fittest?

DevOps is all about collaboration — at least in theory. In reality, even though it produces great results, “collaboration comes at a price,” according to Matthew Skelton,  Head of Consulting at Conflux. What goes into a good team structure? Should we deliberately introduce some sort of boundary between teams to make sure one does not overpower the other? The answer is more nuanced than that. Case in point:

Drama aside, to all my Dev colleagues out there, please be considerate and stop killing your Ops partners.

Arvind Soni, VP of Product at Netsil


In the first part of this interview series, we talked with nine DevOps influencers about the DevOps show and who’s really leading it. Plus, since the focus is slowly shifting from “What is DevOps?” to Where do we start?” we invited our DevOps heroes to clear things up for you. 

9 answers: Who is leading the DevOps show? Devs or ops?

DevOps Influencers

Charity Majors is engineer/CEO at Honeycomb.

Mike D. Kail is CTO at Cybric.

John Arundel s the author of several technical books and has worked with hundreds of clients as a consultant.

Gregory S. Bledsoe is a consultant with Accenture, writer, speaker and thought leader.

Jérôme Petazzoni is an international speaker. He previously worked at Docker, Inc.

Thorsten Heller is CEO and Co-Founder at Greenbird.

Eric Vanderburg leads the cybersecurity consulting division at TCDI.

Quentin Adam is CEO at Clever Cloud.

Hans Boef is a Developer Advocate at IBM.

Charity Majors: The center of gravity is moving to software engineers, who sit in the middle of a mess of internal and external APIs and services, trying to craft something meaningful out of it. Software engineers are who we should be building for … not least because there’s no such thing as “operators” anymore. Ops engineers write software too.

Ops isn’t going away, but ops increasingly lives on the other side of an API, instead of sitting next to you at work.  This is great news — you get to rent world-class operations talent by using companies like AWS, Fastly, and other infrastructure providers, talent that you likely could never recruit and hire yourself.

Mike D. Kail: The first tenet of DevOps is “Collaboration”, meaning that it’s about self-organizing teams and moving away from the concept of an individual or group “leading the show”.

Developers are operating, and operators are developing; that’s DevOps.

John Arundel: The point is that they’re the same people, whether they realize it or not. Developers are intimately responsible for how their code performs in production; good developers relish that responsibility because direct feedback (such as being on call) makes better software and better developers. Meanwhile, operators are the people who write the code which provisions the infrastructure, deploys the software, monitors the services, and so on; they’re just as much developers as the developers, but they work on a different codebase. Developers are operating, and operators are developing; that’s DevOps.

Gregory S. Bledsoe: Here’s a DevOps secret:  Mandates from one person or group to another don’t work. When you hand down an edict, you automatically engender at best indifference and at worst passive-aggressive resistance (and sometime macro-aggressive resistance!)  In this case, the only entity that cares about whether the new process or tool works is the person or group that handed down the edict, and everyone else is checked out.  

One of the two core ideas that started DevOps is Collaboration. Collaboration means negotiation, compromise, and diplomacy leading to all the stakeholders feeling like owners of the entire process and toolset, and the outcome achieved. In this case, everyone is motivated to solve resulting implementation problems. This is the genius of Deming’s point: turn everyone into agents of transformation.

To bring this back to the answer to the question: If any one person or group is pushing DevOps onto others, it isn’t DevOps.

Jérôme Petazzoni: It takes two to tango, so I’d say both! The best developers are the ones who know operations (and how to write code with operations in mind). The best operators are the ones who know development (and how to automate their jobs). The point of DevOps is to make sure that both sides can (and actually do!) talk to each other. In some organizations, the pull to DevOps will come from developers (who are happy and eager to participate in deployment because it enables them to do a better job), in some organizations, the pull will come from operators (who are happy and eager to share the burden with developers to empower them). But you need buy-in from both sides.

SEE ALSO: DevOps trends and limitations forecasted for 2018

Thorsten Heller: From our experience, we’d say developers have taken the driver’s seat position in DevOps. Might be a natural consequence due to the fact the operators often are that busy with keeping things alive, or with firefighting whereas a developer’s mindset might be more open to the new things.

Eric Vanderburg: It depends on the company and the culture. One element of the culture that can be an indicator of leadership frame of reference is where senior management got their start. Those that primarily started out in the services space sometimes have more operations-focused leaders spearheading DevOps while those that started with a software concept more commonly are development focused.  Frequently, DevOps leaders include the CIO, chief architect, director of operations, CIO, or director of software development.

Operators are often busy with keeping things alive, or with firefighting whereas a developer’s mindset might be more open to the new things.

Quentin Adam: I think the majority of the demand comes from the developers’ side, from a long period of time where infrastructure stagnation and frustration have lead to this rush to push ops to give developers more space on management… Which is sad because DevOps has to be a common and shared approach to help the whole team become more efficient, without overpowering one another.

The result is often a “hello world”-driven architecture, mainly based on deployment agility sacrificing stability, monitoring, uptime and security to the rush. The cultural gap with sustainability is clearly coming from the ops side and is not filled today. I hope the relationship will be more balanced in the future.

Hans Boef: For what I see, developers are taking the lead during their daily work. They need to set up a pipeline during the development process. In the various steps in this process, they arrange the right persons to do their jobs.


The focus is slowly shifting from “What is DevOps?” to “Where do we start?”

How do we answer the second question?

Charity Majors: You start by making software engineers responsible for their own services. Putting them on the hook for the quality of their own code shortens the feedback loop and aligns their incentives with their users.  Operations is simply ownership and responsibility for outcomes.

No service really needs an operator.  They need owners.  

Mike D. Kail: The second tenet of DevOps is “Automation”, so I would first start with the basic manual tasks that can be automated, measure the productivity gains, and continue along that path. I will also add that ensure that the tasks that you automate are actually needed, meaning that they will serve to increase productivity and efficiency.

Leveraging cloud technologies is the next natural step for an organization adopting Continuous Delivery and DevOps ways of working.

John Arundel: Put your developers on call for production.

Gregory S. Bledsoe: Every organization is a special onion.  The reasons or pathologies that have resulted in the current process don’t suddenly go away because you want to do DevOps. Customarily organizations want to look at examples of what everyone else is doing and copy that.  

This is exactly backwards, what Deming called “managing for result” instead of managing the cause. Results are side effects of effectively managing the cause, and this requires two things.  A deep understanding of the operating principles of DevOps, and a deep analysis of the causes and misaligned incentives that prevent these solutions from emerging.  

An organization often needs outside help to do this.  It is tough to see your own forest for the trees, and both Deming and Drucker, whose principles form the foundations of DevOps, were big believers in introducing someone new into the scenario to diagnose what’s in the soup your swimming in.  This comes down to the power of the invisible bounds of culture.  

Jérôme Petazzoni: I once said, “one way to start your DevOps journey is to get started with containers.” But I have also said, “using Docker (or containers) doesn’t mean that you do DevOps.” I stand by both statements, even if they sound contradictory at first. Using containers (to facilitate onboarding and achieve consistent development environments, for instance) is a good way to get started.

From there, you can move on to reproducible builds. Continuous integration is a great next step. From there, you can explore continuous deployment for QA and staging (for instance). And eventually, to production. It’s important to make sure that all teams are on board at each step, and remember that tools like Docker and Kubernetes are just tools, and can be misused.

Thorsten Heller: First thing to start: Mindset. Changing the mindset and understanding both on the developers and the operators’ side to make all of them understand the benefits and “what’s in it for me”. Then organization. And in the end maybe tools.  

SEE ALSO: Taking the pulse of DevOps: “Kubernetes has won the orchestration war”

Eric Vanderburg: DevOps can begin from the ground up or the top down.  Many successful DevOps stores started as a grassroots initiative. However, at some point, grassroots DevOps initiatives will need to have top management support. Likewise, top-down approaches will need to have the buy-in of those in development and operations for the change to be successful. Leadership provides the funding and direction, but cultural change requires a much larger percentage of the company to take place.

Quentin Adam: There are simple and more technical questions to answer. If you really want to change the way it works, management has to change its point of view. Lots of companies have different budget and incentive between the ops team and the dev team. Basically, you have developers that need to ship new code to production as fast as possible to maintain the edge of their company, and on the other side, you have ops that are incentivized on making sure everything is stable, safe, and to reduce production costs. This leads to a conflicting culture inside the company.

The best way to make them work together (the real idea behind DevOps) is to reunite the teams with only one budget and organization, with in-line goals. It will be a good signal from top management to help teams implement DevOps for real.

From a cultural perspective, developers need to understand some networking and system level stuff. The Ops need to think about the future and learn how to code.

From a tech perspective, I think the best way to “go DevOps” is to start a clear inspection of the code base tooling: Is the project buildable in one command? Makefiles everywhere? It’s the first question to ask because DevOps is mainly automation of the ops tasks. And the first thing is being able to easily build every source code in the organization. Building solid bases is important, more than setting up a complex distributed workload orchestration system.

Start by automating things you already do. If you create lots of MySQL databases, then automate database creation, monitoring and backups; you will only be good at it if you do it often, you need to automate things you really do, not the hype stuff.

From a cultural perspective, developers need to understand some networking and system level stuff; learn about Linux, containers, systemd and many others things to be able to speak with the ops. The Ops need to think about the future and learn how to code.

Hans Boef: I think we need to share best practices, influence the right people, educate developers/operators etc.


In the second part of the interview series, our nine DevOps influencers weigh in on the importance of incorporating security into DevOps, the areas where automation is really needed and the role of testing in the CI/CD pipeline. Stay tuned!


Are your calendars marked for JAX DevOps 2018? If you’d like to know more about the latest trends in DevOps and meet the top movers and shakers in the global DevOps scene, join us in London between April 9-12, 2018.


Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments