Believing These 6 Myths About DevOps Keeps You From Growing

Having a DevOps team doesn’t make you DevOps

Let’s talk about a few myths/objections you may hear to DevOps within your own company, and you want to think about well, does this work?

So let’s say this person says we’re already doing DevOps. We have a QA and release team. That doesn’t count. DevOps doesn’t mean having a team that does QA and testing. DevOps means that you have a cultural shift in how you think about delivering software. It’s a mind shift. It’s a team shift. It’s not about separating out disciplines saying well, we have a team that ships. Having a release team does not make you DevOps. Arguably, having a DevOps team doesn’t make you DevOps.

Having a DevOps team doesn’t make you DevOps — James Bragger

You want to have feature teams, software teams, service teams that focused on a customer-facing service… that have a bunch of disciplines embedded that let them ship software faster. This person still may say well, this philosophy doesn’t scale to companies of our size. That’s great if you’re a startup. That’s great if you’re five people in a garage. We are, you know, a Fortune 100 company that has 10, 000 developers. We’re not doing DevOps. And that’s really not the case.

You’re seeing some of the largest companies in the world adopting and consuming this. Even my own experience took this from a couple of dozen developers up to hundreds of developers in about a year. So this is something that has scaled for some very large companies. You’re seeing a greater focus, frankly which is exciting, on actually doing DevOps in the large… and so this isn’t something that is designed for small departments, small companies. Instead, this is something where there are lots of case studies.

Another objection might be well, we don’t have the tech skills that startups do. That’s fair. It’s understandable that companies that are born in the cloud or born as software companies have a different skill set. Now, as Adrian Cockcroft, former lead of Netflix used to say to CEOs and CTOs who would make this claim would be well… we hired those people from you like we found the tech talent from you. They didn’t come out of anywhere. And so often it’s about investing in your own folks.

Another core objection I’ve heard is executives don’t think IT has value and it’s actually decreasing our IT spend. This is the fallout from not having a lot of trust between the units. And so instead, IT is just seen again as a body shop, as a group that is the department of number that makes things difficult. And so sometimes this is where you do have to start incubating these ideas proving that IT can actually deliver a ton of value… by delivering software with some unique insight while not being irresponsible and just making bad choices. Instead, IT has some good processes and talent, and procedures. They can help you deliver software if you streamline it. In so many cases like this, you have to start by incubating the idea with a smaller team, smaller service, and then prove yourself. Start to build that trust back, and then all of a sudden you probably will see a change in how IT is invested in.

Now I’ve also heard, and it’s a fair objection, is our compliance needs are too complicated for this. That’s great that you’re doing this for your app that adds stickers to a picture. We actually transfer money between banks. Again, that’s a decent issue to bring up, but what we’ve actually seen in a lot of cases as an industry is that DevOps increases your security profile. You have a better audit trail because all of the steps are automated. Operations teams aren’t just logging into boxes and making changes. Everything is done in something that can be audited later. You’re seeing security built into the deployment pipeline… where you’re doing code scans, where you’re actually doing penetration testing afterward. You’re doing a number of things to make sure that your code is actually more secure end to end… and then in production running in a way that’s much more secure by using automation. So in many cases, you’re working in the most compliant environment possible. You’re able to do DevOps.

Now you may have an objection that says look, my company buys commercial software. We don’t build anything. That may be the case. Many shops buy versus build, and so there is a massive shift though right now to becoming build versus buy. And there are certain things you always buy. You should not be building your own database from scratch right now. That’s probably a waste of time. You should not be building your own container orchestration engine. There’s good technology out there. So in many cases, it’s about choosing the right things to build, not just simply switching over and building your own CRM system. But in many cases, some of the problems you’re trying to solve nowadays don’t have a commercial software that does it. Or if you do, you will be doing a very weird customized flavor of it. So as you start thinking about customer experience… in many cases, you’re introducing new software experiences that weren’t thought of 10 years before by your company. And so it’s about looking at some of those unmet needs, looking at what job to be done your customers are after… and you’re probably going to find some software that you need to build to satisfy that. One that we definitely see from time to time is simply this is just another fad. I can wait this out. This is a rational unified process. This is maybe even agile.

Alright, these are things that I can just wait this out. My career will continue with no change.

I don’t think that’s going to be the case here. I think we’re entering a place where this is the new normal… and this idea of being customer-centric and using the software as an engagement mechanism with our customers, that’s not going away. As we become more mobile, as we integrate partners differently, as we have all of these different experiences, the software is going to power that. And if you don’t become software-oriented, you’re simply going to be overtaken by someone who is.