Q&A with Mike Kavis on Enterprise DevOps and Driving Organizational Change

Updated on February 5, 2016 by UpGuard

Q&AI recently had the opportunity to sit down with Mike Kavis (@madgreek65), VP/Principal Architect at Cloud Technology Partners, in preparation for a webcast we’re hosting next week and asked him a few questions. He was kind enough to entertain my line of questioning and provide some of his thoughts. If you don’t know Mike, you should, but here is what you need to know...

Architect, author, analyst, advisor, and board member. Mike Kavis has served in numerous technical roles such as CTO, Chief Architect, and VP positions with over 25 years of experience in software development and architecture. A pioneer in cloud computing, Mike led a team that built the world's first high speed transaction network in Amazon's public cloud and won the 2010 AWS Global Startup Challenge. An expert in cloud security, Mike is the author of "Architecting the Cloud: Design Decisions for Cloud Computing Service Models (IaaS, PaaS, SaaS).

Mike spends his days advising some of the largest IT Enterprises in the world (as well as start-ups) about cloud computing and DevOps, so this was a walk in the park!

Q: Is DevOps typically aligned with the business?

Yes and no. Most businesses buy into the promise of delivering software more frequently so there is often buy-in from the top. And where there is agreement there is an opportunity for success. Inversely, when a DevOps initiative is driven bottoms-up or “grass roots” without business alignment, I find it is very hard to achieve long-term success. I have seen examples of where the grass roots movement from within IT come together as a collective team - app, dev, ops, security, PM, et. al. and they start delivering functionality quicker than once thought possible. This catches on sometimes, but sometimes it only works with certain teams who are self-motivated to make things better. It is hard to drive that change throughout the organization without people at the top driving it.

Q: Does DevOps equal IT Automation?

A lot of people confuse automating things with DevOps. IT automation is something you do, but it is not DevOps. CI/CD is something you do, but it is not DevOps. We are starting to deliver to market faster, but too often at the expense of quality and reliability which is a drag on customer satisfaction. This is what happens when we continue to operate in silos – development cranks out code that they or IT Operations can’t adequately support. So the business may get software faster, but it creates new bottlenecks.

Don’t automate what you don’t understand.

Q: From your experience, how often is culture actually play a part of DevOps implementations?

If culture doesn’t change then DevOps doesn’t work.

DevOps requires you to solve problems differently. Organizations that don’t address the cultural aspects are simply automating waste. Most enterprises I work with are trying to get a handle on culture, but there is no easy button for this stuff. When you co-mingle two teams who are motivated by different incentives, it puts culture front and center. Where I see success, I see full buy-in from the top and being driven from the highest levels. Most companies understand they have to change the culture, but they just don’t know how.

Q: Any advice for anyone on their own DevOps journey?

Don’t forget the HR side of the house.

Human resources needs to be engaged. Incentive structures need to change and new skills are required for the new world. So you will need HR’s help to train and hire people that understand the customer and who care about the operations guy.

Reward people for fire prevention, not fire fighting.

Traditionally in an enterprise the groups are organized around silos to deliver products. Hence, they are motivated to get their product out and most likely are incented to ship it and be done. But in our ‘always-on’ world, we must change the way we look at the customer by rewarding for behavior that motivates teams to be proactive, not reactive in order to deliver the necessary quality and reliability that is expected in software delivered as a service. Changing perspectives is fundamental to putting the customer-first.

Make quality & reliability a top priority.

Whoever is prioritizing the backlog, whether it is a product manager or an IT person, make sure they are accountable for quality and reliability and not just the speed to market. Otherwise, they won’t invest in “IT features” – things that make the systems reliable, highly automated, and repeatable.