Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs or on the blog for current information.

The term DevOps is getting a lot of attention these days, and for good reason: adopting DevOps practices helps teams work more efficiently, ship better code and make customers happier. But along with the term’s increasing popularity, we’ve also seen some common pitfalls teams attempting to “do DevOps” fall into.

(This list is based on the webinar ‘DevOps: You’re Doing It Wrong’ that we hosted in November featuring our CTO Rob Zuber and Andrew Homeyer, founder of

1.You have a “DevOps” team

The concept of DevOps was coined to counteract the “wall mentality” that often exists between development and operations teams, as a way to imagine those teams working more closely together and to see them embracing some of each other’s practices. So when done right, DevOps is a cultural shift adopted by your entire engineering organization—not one team brought on to “do DevOps.” The real challenge of DevOps is getting your developers to think like operators and vice versa.

2.You’ve stopped trying to tighten your release cycles

If DevOps means shipping fast and often, how fast is fast enough? It really depends. Moving to DevOps is about gradually getting closer to a fully continuous deployment model. If you’re in an enterprise and shipping every six months, eight weeks probably feels really fast. But if you’re a startup, eight weeks is a sign that you’re probably delivering a ton of work at once. Instead of measuring how often you release, start measuring how painful each release is. When something is finished, can you deploy it? If the answer is no, what can you do to remove blocks? Can you chunk code into smaller pieces? What about adding feature flags or toggles? Eventually, deploying code should be a non-event. While eight weeks may be the goal for larger organizations, we tend to see a series of thresholds: once a team is deploying weekly, it’s easier to move to a nightly deploy. After that, we start to see deploys quickly ramp to 20 to 30 times a day. This is when things really start to get continuous.

3.You treat your development team as a cost center

Staffing is expensive, and developers can be some of the most expensive staff a company employs. Many organizations view this expense as something to be contained, but this isn’t the right way to think about it. Instead of thinking solely about cost, companies should be focusing on maximizing developer productivity. The best way to do that is to ensure developers are doing work they’re excited about. Here’s the thing: engineers joined your organization because they wanted to solve interesting problems, namely: the problem of your business. So the best thing you can do is remove everything that stops them from working on that problem. The biggest offender? Ineffective tooling. When developers ship in fast cycles and see their work’s impact on customers, they take more ownership of their code, and are more motivated to put out the best quality work they can. By providing them with frictionless tooling and a feedback-rich work environment, you are maximizing your return on your developer investment.

4.You’re doing undifferentiated heavy lifting by building everything yourself

Undifferentiated heavy lifting refers to any hard work that takes up your time but isn’t core to your business. As an extreme example, you wouldn’t build a new email program because you want to send emails to your coworkers; you would sign up for Gmail. Likewise, you wouldn’t harvest your own coffee beans because you need caffeine to work. When you’re in the build vs. buy debate, ask yourself, “does doing this work in-house deliver immediate value to our customers? Is this the secret sauce of our business that we cannot possibly outsource?” If the answer to one or both of those questions is no, then think about bringing in a tool. Other people have made your undifferentiated heavy lifting into their business. So stand on the shoulders of those who have already done the work and focus on the core of your business.

5.You don’t have any tests

The business imperative behind DevOps is that teams working together can move faster. One way to speed up delivery cadence is by reducing the paranoia factor when deploying new code via automated tests. Shifting the burden of validation away from manual testing into automated tests is a time investment, but it’s one that lets you deploy code exponentially faster. Automated testing buys you assurance that you’re checking exactly what you checked last time, and keeps you feeling secure even when others have made changes in the codebase.

6.You have too many tests

Are more tests always better? Maybe. On one of Andrew [Homeyer, of]’s previous teams, a suite of Selenium webdriver tests took 8 hours to run. And that suite included several non-deterministic tests that would sometimes fail for random reasons. Are tests like that improving your ability to confidently deploy? Probably not. A better question than “How many tests do you have?” would be “Do you feel comfortable walking away from your computer after you merge to master?” Having a lean suite of fast, non-flaky tests focused on your core business value will give you the confidence to deploy without fear.

7.Everything is urgent. You get interrupted all the time.

Being continuous is great. Continuous resolution of non-urgent problems? Not so great. The increased reliance on real-time chat comes with the implicit expectation is that you’re responding to every message that comes in. If you have operational issues you need to deal with, it’s good to have access to everyone on the team. But it’s also important to decide how best to invest your time, then block out your day accordingly. After all, the object of the continuous model is to free developers from constant fire-fighting.

8.You spend time merging

If merging always takes a ton of time and lots of collaboration, you’re doing DevOps wrong. It used to require a lot of work to get a merge together: things are constantly diverging, there’s entropy in software, and you want to control that. Therefore, the more easily you can see how your code interacts with others’, the more quickly you can respond if something goes awry. When you do everything in smaller increments, it’s simply easier to manage and recover from any issues. Many developers have had the experience of being “all hands on deck” in a Slack channel when merging. Slack is great for emergencies. If your emergency is ‘merging’, Slack should not be the answer. Take a different approach: continuous integration, or trunk-based development, for example. Find ways of minimizing the increments that you’re merging with other people’s code.

9.Deploys scare you

Deployment should be a non-issue. As you’re adopting continuous delivery practices, how do you make it safer to deploy code? By implementing tests, yes, but also by thinking about what happens when something does go wrong. Teams should spend time practicing fast rollbacks. Can you ship a fix in 30 seconds? Awesome. By practicing these solutions, you’ll know how to snap into action when an emergency happens.

10.Your developers don’t care about what happens in production

DevOps is about closing the gap — not only between developers and operations, but also between your team and customers. How do you get developers to care more about what happens in production? By removing any handoff of responsibility between their code and what customers see. In other words, have developers do their own QA. This is another way that shortening the feedback loop leads to all-around better code. When developers are the last stop before code reaches customers, they see the effects of failures firsthand, and those failures feel personal. In order to be fully confident their code will work, they’ll want to be doing more than giving their code a cursory glance before deploying. Writing better tests becomes a way to show pride in their work and ensures it works as intended. And the effect of getting developers closer to end-users and letting them see firsthand the value they’ve built: well, it’s infectious. The excitement of building something in the morning and seeing it production in the afternoon is the reason developers got into the industry to begin with, so clearing way for that cycle to proliferate is the key to keeping developers happy and productive.

No matter how long you’ve been practicing DevOps methodology, there is always room to improve, and good reason to do so. Integrating more DevOps practices benefits the entire organization, not just the engineering team. Yes, DevOps is about enabling developers to move faster, see the results of their work, and make quick improvements or fixes as necessary. But by empowering developers to own their work more fully, you create not only a happy engineering team, but an engineering team who can focus solely on creating happier customers, and that is a win for the entire organization.