6 DevOps culture mistakes holding you back

Source- enterprisersproject.com

Having a strong DevOps culture is like having good taste. Everyone wants it – but is everyone equipped with the skills, instincts, and sheer luck needed to actually have it?

The reality is, building a great DevOps culture is easier said than done. Here are the major challenges facing strong DevOps cultures and how to overcome them.

1. Inability to give and listen to feedback

Teams must learn how to give and receive feedback if they are to improve and take each other forward in the process. Engineers and operators are smart cookies with high IQs, but many need to improve their EQs to collaborate more effectively as a team. Teams with high EQ will always destroy those with low EQ because they can learn and achieve more. 

Feedback is about sharing what is working and what can be improved every single day. It’s important that teams don’t just focus on the good or the bad, but rather keep a sharp focus on feedback and bias.

2. The revolving door problem


Part of the challenge facing DevOps culture is the short tenure of DevOps professionals themselves. The average tenure of a DevOps engineer is less than three years. Engineers often find themselves lured away for the promise of better compensation, better equity, or the “next hot startup company.”

This doesn’t do any favors to the ongoing battle to achieve true alignment between Dev and Ops teams: How they can play together when team members are constantly jumping ship, leaving behind unfinished projects, and forcing new people to join and ramp up quickly? If there were more stability in engineering teams, it might be easier to build the foundations of a stable and durable DevOps culture.

3. Well-meaning but time-wasting acts of heroism

Often you’ll be at a developer conference and an enthusiastic, well-meaning presenter is gushing about the unbelievably complex, bespoke platform that her team has built – one that has nothing to do with their core competency. She demonstrates how they spent six months and $300,000 to create it and the whole room bursts into applause.

The “build it not buy It” mentality is one that truly holds back top-performing engineering teams. In 2018, the platform you need has likely been built – and built extremely well – by a third party. Save your engineering heroics for what your customer actually requires; the rest is a needless waste of time and resources. Be an expert in your business, not the tools business.

4. The term “DevOps” is a problem

If you ask many high-performing engineering teams about DevOps, the response you’ll often get is an eye roll – even if those teams are uncommonly good at DevOps. The word has been beaten down, over-publicized, and over-discussed. (I know, this article doesn’t help that situation.)

If DevOps refers to the cultural alignment of development and operations so that both teams are responsible for the success of production environments, then the term has enormous value. But if the word has been drained of all meaning by a tsunami of think pieces and keynote presentations, then it’s difficult to have a meaningful discussion about it.

Try to remember that the concept has value, even if it’s been beaten down by so many analyses, conversations, and misunderstandings.

5. The right culture isn’t modeled from above

You all know the truth of this statement: There’s no culture unless it’s shown by example, set by the teams above. It takes a superhuman effort for a team to enact its own unique culture within an organization that doesn’t itself value culture or take it seriously.

If you have an organization where the executive and management team isn’t truly facilitating team alignment, including between the developer and operations teams, how can a DevOps team survive and thrive? Culture comes from the top.

6. DevOps goals aren’t aligned to business goals

99.9 percent of companies using DevOps are wielding it as a catalyst to drive business outcomes faster, and a strong DevOps culture is one that truly understands the levers of its business. DevOps is not about having a team of “rock stars” that improves technical KPIs; in fact, measuring availability is pointless unless you can measure and report the real business impact.

 Technical metrics are great, but goals drive behavior – and goals that focus on the needs of the business constitute the foundation of a solid DevOps culture.

How to beat the DevOps barriers

I’ve spent a lot of time describing the barriers that keep DevOps teams from reaching their full potential. But the reality is, there are plenty of positive forces helping DevOps teams build strong cultures. For one, the will to do so is stronger than ever: Companies want strong DevOps organizations to help them achieve business goals. For another, technology is better than ever and can help teams focus on the same shared metrics and set of goals.

Wherever you find the twin enablers of genuine will and solid technology, a strong DevOps culture can’t be too far behind. In addition to will and technology, companies seeking to build that culture must:

  • Focus as much on EQ as IQ, making sure engineers and operators really listen to each other while building a DevOps culture from the ground up. This will also help maintain collaboration and stability on Dev and Ops teams, making constant turnover less of a cultural and business problem. (See our related story: 10 things leaders with emotional intelligence never do.)
  • Stay in the business you’re in: Allow engineers to focus on what your company was created for, rather than distracting them.
  • Have open discussions on what DevOps really means, and what it means to your teams, independent of the hype that the word has taken on in recent years.
  • Ensure leadership is taking DevOps seriously by showing, not telling, how to build a collaborative culture – and by linking DevOps goals directly to business goals.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x