However, any time you attempt to make a massive change to the undercurrent of your organization, you face challenges and have to deal with setbacks. As you transform to DevOps, you’ll discover unique speed bumps for you and your team to get over.
Although you can’t possibly predict every obstacle you’ll face, this article can prepare you for the ten most common DevOps pitfalls. Remember that however you approach your DevOps practice, your priorities should remain focused on people, process, and technology — in that order.
Failing to prioritize culture in your DevOps project
More than anything else, DevOps is a cultural movement. The culture you build at your organization will make or break your DevOps practice. Your DevOps culture must emphasize collaboration, trust, and engineering empowerment. If you nail automation but miss those cultural components, you will likely fail.In truth, tooling doesn’t matter that much. The tools you have at your disposal are more similar than not. Although the problems they solve are important, none of those problems can compare to the nearly endless frustration of trying to unite developers and operations folks — as well as other teams, like security — in a traditional engineering organization.
DevOps seeks to galvanize engineers (as well as business groups). It creates a foundation on which everyone can learn, share, and grow. That personal acceleration will fuel your entire engineering organization to create better DevOps software, faster. The engineers you have on your team are the most valuable asset you have. Treat them well by giving them respect and the room to do what they do best — engineer solutions.
Leaving others behind as you move forward with DevOps
Making the case internally for DevOps will determine the type of foundation you build for your culture. Look for fertile soil. If you move too quickly and don’t convince key people of the importance of a DevOps transformation, people will watch your movements with skepticism and leap at the first opportunity to show everyone you’re wrong. That is not a fun position to be in, and you never want to start this journey with people waiting for you to fail.To be successful, you need everyone on board the DevOps ship, even the naysayers and skeptics. Engineers can be skeptical. After a decade or two in this industry, they’ve seen a lot of ideas and new approaches come and go. They can easily shrug off DevOps as “just another failed approach” to the same old problems. And if you implement it poorly, DevOps will indeed be just another failed approach. You and your team must persuade others of the potential and take action in ways that invite everyone to the table.
Try convincing executives with data and the potential for accelerated software delivery. But engineers need to know how DevOps will make their jobs more enjoyable. Show them how DevOps aligns with business needs and reduces friction along the software delivery pipeline.
Just be sure not to oversell the concept. DevOps challenges will happen. DevOps is not a silver bullet and requires intense work at the beginning to ensure that the team creates a learning culture in which engineers are free to make mistakes and grow.
After you reach an event horizon where enough people believe in DevOps, you can proceed with the knowledge that you have the support of your organization and the people within it.Forgetting to align incentives in your DevOps project
If you don’t set out to align incentives with what you expect from certain teams or specific engineers, more challenges arise. The real tool of DevOps, if you can master it, is empowerment. You want to empower your engineers to do their job well, free from interference. You hired talented engineers, so trust their ability to fulfill their responsibilities.For example, when developers serve on an on-call rotation, some organizations frame it as a bit of a punishment. “You built it, you support it,” doesn’t exactly fill people with happy feelings. Instead, it feels like just another form of siloed responsibility. But a humane and evenly distributed on-call rotation not only empowers developers to take ownership of their work, it also creates learning opportunities for the entire team.
In DevOps, you don’t punish engineers for imperfect work; instead, you share responsibility and cultivate an organization that values learning and empowers everyone to be curious as well as participate in areas of tech in which they’re less familiar.
Aligning incentives and creating opportunities for collaboration drives your goal of improving your products and better serving your customers. If everyone is aligned toward the goal of creating amazing services for your customers through DevOps, you will see the group begin to galvanize.
Keeping quiet about your DevOps project
DevOps is the antithesis of secrets and backroom negotiations. Instead, it lays everything out on the table and forces you to trust the integrity of the people in your organization. When you first introduce open communication, conflict may seem to increase. It doesn’t. Instead, you’re simply seeing the friction points for the first time. Instead of leaving conflict to brew beneath the surface, people feel safe enough to raise their concerns and express their opinions.An important aspect of open communication is to keep it going throughout the entire product life cycle — from ideation to production. You must include engineers in planning discussions, architecture decisions, development progress updates, and deployments.
Although this emphasis on communication creates more verbose discussions, it also enables engineers to have visibility outside of their core area of expertise, which in turn empowers them to advise others while equipped with the context necessary to make sound decisions.
Keep the customer — and what they expect from the product you’re building — at the center of every discussion and decision. If you stay aligned on that goal, you’re sure to move forward together as one unit.
Forgetting to measure your DevOps progress
Measuring your progress is crucial to DevOps success. It lends you validation when making the argument for DevOps to doubting stakeholders, helps you convince holdout executives, and reminds your engineering team how much they’ve accomplished.Before you make a single change, create a baseline. Choose a small set of data you want to track through your entire process. This data informs your decisions and serves as fuel to continue pushing when you hit setbacks. Potential measurements include:
- Emstakeployee satisfaction: Do your engineers love working at your organization?
- Monthly recurring revenue (MRR): How much money are you making from customers?
- Customer tickets: How many bugs are reported by your customers?
- Deployment frequency: How many deployments do you have every week or month?
- Mean time to recovery (MTTR): How long does take to recover from a service disruption?
- Service availability: What is the uptime of your application? Are you hitting your current service-level agreements?
- Failed deployments: How many releases cause service disruptions? How many have to be rolled back?
Micromanaging your DevOps project
One of the quickest ways to undermine your engineers is to micromanage their work. Dan Pink, author of the book Drive, believes that motivation at work is driven by three factors:- Autonomy
- Mastery
- Purpose
Trust can be a DevOps challenge. It is absolutely critical to DevOps organizations. You must trust your colleagues, peers, engineers, managers, and executives. You must also trust the roles and responsibilities of the various departments in your organization — which isn’t to say that you will never have conflict. Of course moments of friction will happen between human beings. But minimizing those moments and enabling healthy conflict resolution is what distinguishes DevOps-focused engineering teams from their competition.
Changing too much, too fast
Many teams make too many changes too quickly. Humans don’t like change. DevOps is beneficial over the long term, quick changes to the normal way of doing things can be jarring to engineers.One failing of DevOps is that it implies that everyone lives in the greenfield (new software) with rainbows and unicorns. It can sound like, “If only you can get your team to work together, software development will be easy!” That’s not true. Software engineering is hard and will always be hard. That’s one thing most engineers like about it. You enjoy a challenge. But challenges should be stimulating, not stressful.
DevOps doesn’t aim to remove all the intellectual challenges of engineering. Instead, it offers to minimize the friction between humans so that everyone can focus on their work. If you attempt to make too many changes too quickly, you can find yourself in the middle of an all-out revolt — Mutiny on the Binary.
Choosing DevOps tools poorly
Although you are deprioritizing tooling in DevOps — and rightfully so — tooling is still a factor. Even the least important aspect of DevOps contributes to your overall success. The tools you select should solve the problems your engineering team experiences, but should also align with the style, knowledge, and comfort areas of your existing team.Don’t be afraid to try several solutions and see which one fits the best. Dedicating a few weeks to a minimum viable product (MVP) or proof of concept (POC) to test a tool is well worth the effort. Even if you end up throwing it away, “wasting” the engineering resources is preferable to going all-in on a particular technology only to find out a year later that it’s not a good fit.
Fearing failure of your DevOps project
Failing fast is a short way of saying you should constantly be iterating to identify problems early in the process without spending a ton of time and money. t’s something that a lot of people in tech talk about and few actually implement because it requires rapid iteration in an environment in which mistakes have a small blast radius and are easily corrected. Too often, companies claim a fail-fast mentality and instead fire the first engineer to delete a production database. (As if any engineer out there has never deleted a production database . . . .)In the context of DevOps, however, you’re better off failing well than failing fast. Failing well implies that you have monitoring in place to alert you to potential problems long before the situation impacts customers. Failing well also implies that you’ve designed your system in a segmented way that prevents one service that’s falling over from cascading into a systemic outage. But organizations that fail well go one step further as well: They don’t blame people. Instead, they look for failures in systems and processes.
Kaizen is the Japanese word for continuous improvement. In DevOps, kaizen means to continuously improve your processes. It’s not some sexy transformation that has a beginning and an end. The goal isn’t to go from zero to perfect. Instead, DevOps encourages working slowly and gradually toward making one thing better, every day. If you leave work each evening knowing that just one small aspect of work is better because of you, wouldn’t you feel satisfied? A lot of engineers feel that way.
Instead of attempting to avoid failure at all costs, DevOps insists on a growth mindset. Failure isn’t a marker of stupidity or poor preparation. It’s a marker of growth and a necessary step in innovation. Innovation is an outcome you should be willing to pursue, even if it means that you occasionally fail.
Being too rigid will create DevOps problems
DevOps is not prescriptive, and that’s both the best and worst thing about it. DevOps would be so much easier to implement if you had a list of ten steps you could take to achieve DevOps nirvana. If only it were that easy! But humans don’t work that way, and groups of humans — such as on engineering teams and in large organizations — create even more complexities that need to be addressed.Although no blueprint for building a DevOps organization exists, you are empowered to tailor the methodology to practices that work for you and your team. You know your organization, and as a knowledgeable expert, you should think outside the box when applying the fundamentals. Some of the things in DevOps will fit you perfectly. Others will feel like wearing a jacket that’s just one size too small. That’s okay.
You’re going to make mistakes. No one is perfect. But if you let go a bit, empower your engineers, and trust your team, you will see awesome outcomes. Just get started. And remember: invite everyone to the table, measure your progress, prioritize culture over technology, and empower your engineers to do what they do best.
