What Is a DevOps Mentality?
What Is a DevOps Mentality?
DevOps requires a certain mindset to improve communication between team members and reach real solutions to increase collaboration and success.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
So you want to build a DevOps team? What does that mean, and where do you start? DevOps isn’t a job title or a defined set of technical skills, it’s a mindset. You can have the best and brightest engineers but unless you have the right mindset a DevOps initiative at your organization will fail. DevOps is about culture more than it is about technology.
Look at the agenda for any DevOpsDays program the majority of talks are about culture, not technology. The technical things are easy, the people are hard. A DevOps mindset means you understand there is no single hero or person to blame. To ship a successful product cross-functional collaboration is necessary. The software that is written by engineers runs on systems that are managed by IT operations and sold to customers. The customers read documentation from technical writers and receive help from technical support or developer relations teams. Effective collaboration requires empathy, communication, and a willingness to learn and change.
Empathy is the ability to identify with another person’s feelings. It’s not about feeling sorry for them or sympathizing with them but being able to understand and relate to why they are feeling that way. As Brené Brown describes in this video, empathy allows us to build connections. If we aren’t connected to one another we aren’t unable to work together as a team or understand the needs of our customers.
When a customer requests a feature is your immediate thought “That’s stupid, why on earth would somebody need the product to do that?” or do you think “That’s a unique use case, I hadn’t thought about using the product in that way, I can see why the customer is frustrated the product could definitely be improved for that use case.”
Empathy isn’t just for dealing with customers, showing empathy to coworkers is also needed. Instead of being frustrated and arguing about the security audits required before an application can be rolled out think about the consequences of a security breach. Chances are the people putting up the roadblocks don’t get pleasure out of delaying releases, they are doing it to protect the organization and your customers.
One of the benefits of empathy is creating a more inclusive community. When we are connected to one another and can relate to how others are feeling people feel like they belong. When customers feel their needs are understood and the product is easy to use they are more likely to tell others and become a more active part of your community.
It is difficult to collaborate if you don’t communication. It doesn’t matter how you are communicating Slack, email, or hallway conversations communication is crucial. Communication is two-sided it is about listening and talking. If all you are doing is talking you’re not communicating.
Instead of jumping in and taking over when a problem is presented, ask the person, “What do you need from me?” Maybe they need guidance, maybe they needed a place to vent, maybe talking through the problem was all they needed to get a fresh perspective and solve the issue. It’s not always easy to ask a good question or give a good answer. A great resource to help with his is Julia Evans two-part blog on asking good questions and providing helpful answers.
Asking good questions becomes even more important in times of crisis. After an incident occurs many DevOps teams will conduct a blameless post-mortem. It’s easy to want to assign blame, but assigning blame isn’t very empathic. The five why’s are often used as a technique to identify but there is a belief that “Why?” is the wrong question. In his critique of the five why’s John Allspaw suggests we ask "How?" instead. Asking why can lead to closed-ended answers and we miss critical components. Asking how requires events to be described, providing more data, and building a deeper narrative. Asking why can close lines of communication while asking how can lead us to answers we would otherwise not have.
A Willingness to Learn
Technology is always changing, and as a result, we are always learning. We learn new frameworks, new programming languages, and new ways of deploying applications. If you’re not willing to learn new technologies and change with the times you could find yourself out of a job.
A DevOps initiative not only requires you to learn new technology but also learn different ways of communicating and engaging with others. If you are not willing to learn and change your mindset your DevOps initiative will fail. Think back to the notion of blameless post-mortems. Post-mortems can only be blameless when failure or mistakes are seen as a learning opportunity and not a sign of weakness requiring punishment.
Change can be scary and is often met with resistance. With empathy and communication change can be easier. Be open to new ideas and perspectives.
DevOps isn’t something you buy or a technology you utilize. It’s about the people and culture. Having a DevOps mindset is more important than implementing continuous integration strategies or automating processes.
Opinions expressed by DZone contributors are their own.