Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News DevOps beyond Development and Operations with Patrick Debois at QCon London

DevOps beyond Development and Operations with Patrick Debois at QCon London

Patrick Debois talked at QCon London about thinking of DevOps beyond development and operation silos. DevOps is inherently complex, and there are other risks, challenges, and bottlenecks outside the software delivery pipeline where collaboration is vital, for instance, when collaborating with other groups like suppliers, HR, marketing, sales, finance, or legal.

According to Debois, many people talk about the DevOps pipeline and its impact on development and operations. However, there’s also an impact on HR like doing the right hiring, sales doing the right pitch, or marketing having feedback whether customers like the outcomes or not. DevOps has helped to optimize for developers creating new features, creating a positive impact on the operational side. Nonetheless, people tend to continue optimizing the software delivery pipeline, but perhaps the bottleneck moves outside of this scope. Companies need to think continuously about where the next bottleneck is.

Debois talked about his experience when growing a startup where they learned that instead of only looking inwards in their pipeline, they had to find where the real bottleneck was. One of their first bottlenecks was external to the company with a supplier. Debois was sending feedback to the supplier, and they were prioritizing work to fix issues. Another bottleneck was in HR as the company was growing, and they were having problems hiring people. So, Debois started to collaborate with HR by attending local meetups and writing articles about how their culture was to attract talent. These bottlenecks were beyond the delivery pipeline, and Debois stressed the importance of systems thinking by saying:

If you have the idea of dev and ops just working together to try to fix a problem of the build pipeline, the problem is way bigger. And we can attribute way more to the organization than we think. Always think about where the next bottleneck is.

During his time on the company, Debois found out about other bottlenecks in departments like marketing, sales, legal, or finance. However, Debois ended up leaving the company after working long hours and being exhausted: "At some point, I thought we were compensating in engineering the fact that we weren’t selling enough." Additionally, Debois said that "they tried everything they could on the collaboration perspective of having all these groups work together, but still, our biggest bottleneck was that there wasn’t a market fit."

InfoQ interviewed Patrick Debois, director of DevOps relations at Snyk and one of the authors of The DevOps Handbook, about the possibilities of having a new term in the industry after exploring new silos and the takeaway from his talk.

InfoQ: Do you think we’ll need a new name for DevOps like BizDevOps after considering other silos from the company like HR, sales, or marketing?

Patrick Debois: New names will survive only if they make sense. I’ve seen DevDesignOps, NoOps, FrontEndOps, and other variations. They’re useful because it helps to create a new mindset or ideas. You have to be aware that whenever a new idea or buzzword comes around, like DevSecOps or SRE, there’s value to it because it brings a new perspective to the table. It doesn’t mean that DevOps as a term will exist forever. Some will say that what will survive is the delivery pipeline, and others will think broader. So, new terms will inspire new things to happen.

InfoQ: What is the message behind your talk for thinking beyond dev and ops?

Debois: We’re (technical people) not so special in the company. Development and operations are a tiny bit of the spectrum from the business. Technical teams bring value to the company. You might think you need a pager, but don’t you think the salespeople are on-call as well? It’s been all about the pipeline and technical practices like doing everything data-driven and using metrics, but we can learn from other groups too on how they do work as well.

Rate this Article