Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Q&A with Michael Coté on Devops Adoption and His Talk at DevOpsDays NZ

Q&A with Michael Coté on Devops Adoption and His Talk at DevOpsDays NZ

This item in japanese


Michael Coté is Pivotal's director of technical marketing and also a prominent evangelist, writer and commentator in the DevOps space. He will give a talk titled 'This is not a DevOps talk' at DevOpsDays NZ in October, providing experienced based insights into successful DevOps adoption.

DevOpsDays is a worldwide series of technical conferences covering topics of software development, IT infrastructure operations, and the intersection between them. Topics often include automation, testing, security, and organizational culture. New Zealand will be hosting its second DevOpsDays NZ conference in Auckland from 3rd to 4th October.

InfoQ caught up with Coté, as he prefers to be called, to get a sneak peek into his current passions and the upcoming talk.

InfoQ: Can you please tell us about your current role and the areas that interest you most in the DevOps space?

Michael Coté: I work at Pivotal now, basically in marketing. I go around and talk with large organizations who are looking to improve how they do their software. Most of them want to start using custom written software to programs in their business, as it were. They want to use software as a core tool to innovate their business.

For example, there’s an insurance company that wants to speed up their claims process - from a week to less than a day. You can imagine how they’d also want to use drones to evaluate damage to property.  There’s other companies who, for example, work in the packaging manufacturing business who want to enter the farm-to-table delivery market, working as a service for food providers and others to launch such businesses. If you can think of any type of company - and especially government agencies - there’s all sorts of ways software can improve what they do. 

What interests me about DevOps is that the processes and tools in this sphere of thinking are genuinely new and are demonstrating that they can speed up the application development process, and also make sure the apps actually run in production. As an example, to increase the design quality of their software, most organizations I talk with are looking to release software on a weekly - if not less! - basis. They want to break up their software into small chunks that they release and "test" by putting in front of actual users. The "test" there is to figure out if they’re solved the user’s problem in the right way, or if they need to re-think, re-design, and re-code the way they’ve implemented to feature(s) of the week.

Operating at that speed and using that kind of feedback loop would be damn near impossible without all the cuddly voodoo from DevOps-land.

I also write a monthly column on DevOps (and agile, and whatever else my fingers might type in a given month) for _The Register_. I think y’all have the same spelling problems with words like "virtualisation," "organisations" and "colour" in these parts, so you might like it.

InfoQ: Can you tell us a little about your DevOpsDays NZ talk, entitled "This is not a DevOps talk?"

Coté: Well, as the title would imply, it’s not really too much about DevOps, in the normal sense. Most of what I study is how organizations fail and succeed at improving how they create, run, and use custom written software. I feel like DevOps as we know it is enabling that, but thinks of itself as being lower down the stack than the actual user-facing software. The DevOps community doesn’t usually address all parts of improving software, but it’s certainly a necessary component for doing this like releasing software every week, if not multiple times a day.

So, this talk does a little bit of "why you should care about doing software better" and then catalogs some selections of my best and worst practices work I’ve done ongoing. Much of this is also put together in a little PDF I did last year, Crafting Your Cloud-Native Strategy.

InfoQ: What does DevOps mean to you?

Coté: At this point, I just go off those fancy, helpful diagrams in the annual DevOps Reports. Anything else, for me, is more about "avoiding doing the dumb stuff we've been doing forever."

In a less technical sense, I think "DevOps" is the current word people use when they mean "I want to improve how we create and run custom written software around here." 

InfoQ: Why do you think that so many organisations still get fixated on the tooling and automation aspects of DevOps?

Coté: It’s easy to understand and start using the tools. Also, people in the DevOps thought-lord circuit often don’t realize how much stupid is out there in regular organizations. For example, most people don’t automate nearly as much as you’d think; each year surveys show that only about 30-40% of organizations do CI, even less when it comes to full on CI/CD; and most organizations take months to ship just a line of code.

This is to say: they’ll get huge benefits from just putting DevOps-oriented tools in place.

And, the so called "culture" stuff is hard to really put into practice without a lot of leaps of faith or, you know, trying hard. It’s like your doctor telling you that you should eat more fruits and vegetables to live longer. Sure, but it’s much easier to try and solve that problem by following a specific diet, some circuit training thing, or some other "tool" beyond a bromidic proclamation that you should suck less and be more empathetic.

InfoQ: How achievable is the promised-land of cross-silo, collaborative ownership which brings in everyone needed to innovate, deliver and discover the paths to value?

Coté: It’s very achievable. Senior leadership just has to change incentives to make people do it and quarantine or fire people who resist. This is not only at the lower levels individual contributors, but also the middle management layer. It's all up the senior leadership to make it happen, sometimes all the way up the CEO or board. 

The silo-state we’re in now made sense back at the time and incentives were put in place to create it and make sure it operated as a designed. Now companies managers need to put on some change management coveralls and get to work again.

InfoQ: Through your working with Pivotal clients, have you spotted any effective patterns which help organisations achieve a more effective DevOps adoption?

Coté: Well, that’s my talk. Come and see it!

Also, check out that PDF of mine: Crafting Your Cloud-Native Strategy

InfoQ: What would your advice be to organisations still early along the DevOps journey, or placing more emphasis on tooling?

Coté: They should start small: pick a team of four to six people made up of some developers, operations people, and actual business/customer facing people. Then spend a few days to pick one to three initial projects and just start doing it. You have no idea how you’ll put all this DevOps stuff in place, nor build up the trust and knowledge of how to do it until you start doing it.

DevOpsDayz NZ will be running in Auckland from 3rd to 4th October, where Michael Coté and a number of international and local speakers will share on cultural and technical topics. 

Rate this Article


Educational Content