Top 10 obstacles when implementing DevOps in small companies

Implementing DevOps, be it technologies, processes, or culture, can be daunting. More often than not, the problems start even before the drawing board: do we actually understand what DevOps is?

Some say it’s automation, others say it’s attitude or philosophy, and then some swear it’s all about the integrated tools that work together to make developers’ lives easier. Or should it be easier for the company to roll out and deliver its product? I’m confused. And unless you have written a book on the topic or run several teams of DevOps engineers in an enterprise, so should you.

So let’s talk a bit about the challenges smaller companies may face when trying to “implement DevOps”. Here are the top 10 obstacles that we need to address:

1. The “DevOblivious” Leadership: Picture a company where the leaders haven’t fully grasped the concept of DevOps, and as we have already established, this indeed can be tricky. They start talking about “DevOps” without fully understanding what it really means, what should be accomplished, and very often: how to do it. They want trendy best practices and improved metrics on efficiency and security, and they heard that DevOps is good at accomplishing that. Well, you kind of have to know what you’re doing if you want to succeed.

2. The “One-Tool-Fits-All” Delusion: In an attempt to simplify things, some small companies fall into the trap of believing that one magical tool (or platform or vendor) will solve all their DevOps challenges. They end up with one or several such “magical solutions” that don’t really accomplish original goals or create new problems in other areas along the way. Sometimes they pick a platform that does everything but is not suitable for the company’s specific needs or requires deep knowledge of the said platform to be even remotely useful. It’s like using a Swiss Army Knife for your cooking needs—you can do it, but should you plan on it when designing a kitchen and think that it’s all that is needed to make Gordon Ramsay proud?

3. The “All-or-Nothing” Leap: Some companies dive headfirst into DevOps, expecting immediate miracles. They abandon their existing processes overnight, leaving their teams dazed and confused. It’s like going from crawling to running a marathon without training. The best-case scenario: project results in degraded productivity, stressed-out developers, and lots of head-scratching as to why it’s not working as intended.

4. The “Blame Game” Drama: DevOps requires collaboration and teamwork, but some companies struggle with a blame culture, or more often, a softer version of this called “not my f***ing job”. When something goes wrong, fingers start pointing, and the blame game begins. “Don’t fix something if it isn’t broken” and “Did you try rebooting it?” are two golden rules many IT veterans live by, and it’s hard to let go of the mentality. When it comes to the relationship between developers and operations, it’s not uncommon to dodge and try to bury problems in tickets, hoping they go away.

5. The “Automation Overload” Spectacle: Automation is a crucial aspect of DevOps, but some companies get carried away. They try to automate everything too fast, and then the scope gets out of hand, or common sense gets lost somewhere along the way, leaving developers thinking their way out of the mess with manual workarounds for automation. Ironic?

6. The “Culture Clash” Tragedy: The people are creatures of habit! They are used to doing things a certain way, and when the bright new guy (or girl!) comes in with all those ideas of how the operations should be run, the guys who have done it for the last ten years start to feel betrayed or at very least have serious doubts about all this fuss. After all, traditions are a thing for a reason, and a conservative approach may not be the fastest or most efficient, but it has saved us so many times! Right? And what are this guy’s (or girl’s!) qualifications anyway? Didn’t he just finish college last year?

7. The “Documentation” Disaster: With any significant change, documentation is essential, yet some companies overlook it in the excitement of implementation. They end up with outdated or nonexistent documentation that resembles a comedic script full of plot holes. And it’s kind of OK until that one guy who knows everything decides to leave the company. Or something breaks during vacations. Or there is a new hire that requires training. Or an audit comes. Or…

8. The “Security” Obscurity: Ask any IT professional if security is essential. Yeah, you can guess the answer; however, it is often treated as an afterthought when implementing DevOps. *.* namespaces in Kubernetes, anyone? It works! And since there is no clear documentation or standard operating procedures, you can’t blame the guy for doing it. Can you? While it’s easy and fun to automate, it’s hard to do it securely without negating the benefits of speed and simplicity. Also, security is not fun.

9. The “Tooling Frenzy” Circus: Smaller companies sometimes fall into the trap of adopting every trendy DevOps tool that gets on their radar. It looks great. The name is cool. The product logo is sexy. The promise of improvement is excellent. And it’s open source! Let’s get it in our pipeline already! We will worry about maintenance later, right after we worry about security! Yeah.

10. The “Resistance to Change” Phenomena: Change is never easy, and some employees will resist the DevOps transformation. The Luddites resisted the industrial revolution; the music industry resisted file sharing and streaming; some people resisted COVID vaccines; and that data center engineer will resist AWS. It’s so predictable you can bet your house on it, so it’s probably a good idea to consider it when planning your DevOps implementation.

Most companies fail miserably at the first obstacle, and it gets worse from there, which is no surprise. If you ask a dozen DevOps professionals what DevOps is, you will likely get a dozen different answers. And what is a DevOps professional anyway? Some say it’s evolved server administrator; some others claim it’s SRE, a platform engineer, a developer, a cloud specialist, and so on. There is no clarity in the title. Everyone understands exactly what you do if you tell someone you are an Uber driver. If you tell someone you are DevOps, this can mean anything, and as a person who hires DevOps weekly, I emphasize ANYTHING. So how do we make sense of this DevOps thing? How do we assess and select the best platform, tool, practice, or approach that is truly the best for our specific company with its particular products and people with their specific competencies? If you have a few decades on the horizon, you can try major tools and several different approaches. If you’re feeling fortunate, you can trust that one person’s judgment who seems to know a lot about DevOps and is very enthusiastic about it. If you have a lot of money, you can hire the best consultants and hope they will do this for you. In reality, though, there is no shortcut or universal solution. You must take your understanding of your business, merge it with broad knowledge of the field ecosystem, and then be conservative with timelines. Spend 2-3 times more time on the planning phase and be open to ideas from your team. Start with fundamental decisions. Estimate consequences. Do that, and you will be way ahead of the field. Good luck!

Do you have other recipes for success? Suffered from one of the scenarios I have outlined? We’d love to hear your stories.