DEV Community

Cover image for DevOps Is an Evolving Culture, Not a Team
Kyle Galbraith
Kyle Galbraith

Posted on • Originally published at blog.kylegalbraith.com

DevOps Is an Evolving Culture, Not a Team

There seems to be a growing misrepresentation about DevOps. Sometimes it's represented as another team in the engineering structure. Other times it's a single individual inside of an existing team (i.e. DevOps Engineer). But these perspectives are wrong and missing the point of DevOps in my opinion.

DevOps is a culture, not a team or an individual. It consists of a collection of philosophies, processes, and tools that a team nurtures. It evolves, it's not static because teams and technology are evolving.

It breaks down barriers between teams, it doesn't build new ones. It is engineering-minded folks becoming versed in operations and vice versa. The two become a homogenous one. When done right it can transform an organization and product.

By becoming a homogenous unit development can move quicker. They can iterate on their product or service to better-fit user needs at a faster pace. All while maintaining the quality, delivery, and reliability of the product or service.

How does it work though?

From the outside, this sounds complicated.

To be frank, it can be very complicated in organizations where "siloed" teams are common. In these cultures, operation teams feel as if their jobs are at risk. Development teams feel as if they are being asked to do more on top of what they already do.

These cultures have problems that are deeper than they appear. Often times these feelings or beliefs stem from a lack of trust in the organization. Other times they stem from teams feeling disconnected from the purpose of their work.

Whatever the case may be, these cultures need to be reset in order for a DevOps culture to evolve in its place.

The simplest approach is to rip the band-aid off. In a DevOps culture, the silos are torn down and development is no longer walled off from operations. In a lot of cases, these two teams become one. Meaning the team handles the entire application lifecycle. From development to deployment and beyond, this team is accountable and responsible for each step.

This can feel very chaotic, as is the case when a major process change occurs. But, a great way to combat the chaos is to trust the teams to make the right decisions for them. Nothing will make this change fail faster than not having confidence and trust in the folks making the transition.

By combining the two teams a strong base of knowledge can be formed across the entire team. Operation folks can share their expertise from the deployment and monitoring side of things. Development folks can share their expertise from application development.

This knowledge sharing often results in processes that automate a lot of the repetitive, manual, and slow tasks in the pipeline. This automation expedites the delivery of the product or service. Automation also lowers the friction associated with deployments.

A DevOps culture requires a change in mindset. These teams need to be given the control of the systems and applications they are responsible for. The team owns the entire lifecycle of their systems. As such they focus on iterating quickly, collaborating often, and continuously improving.

This full ownership leads to decreasing inefficiencies, tighter feedback loops, and improved reliability.

What DevOps is not...

I find it frustrating to see organizations and teams implementing processes that run counter to what DevOps is. A team or a single individual is not responsible for DevOps.

To me, this is missing the entire point of DevOps. It is a culture that the entire development team holds each other to. This culture isn't static, it's fluid and evolving as members join the team and technology changes.

Furthermore, the culture of DevOps is going to vary between organizations and even individual teams. This is because one team or organization is not a carbon copy of the other. So you can learn new ideas and concepts from others, but those will meld into your team or organization.

There is a real business impact to be realized in a culture that is backed by DevOps principles. Tight feedback loops and automation associated allow the business to iterate quicker. Faster iterations mean faster decisions and value in user's hands sooner. These benefits are very real, but the implementation to gain these benefits must be done well.

Focus on the benefits and the outcomes that a DevOps culture creates.

  • Development Speed - innovate faster to drive business results.
  • Rapid Delivery - release frequently and reliably.
  • Reliability - release your product or service with confidence.
  • Scalability - automation and reliability allow you to scale your architectures with relative ease.
  • Collaboration - no more walls, more communication, and more ownership.

The culture evolves and so do the processes that realize it, but these benefits are your North Star. This is a collaboration that is meant to unite a team to deliver business results. It tears down walls and expedites the delivery of your product or service.

Conclusion

We have given this culture of fast reliable iterations with increased collaboration and a ton of automation a name. That name is DevOps, but really we could call it anything we wanted to.

The important things to remember with DevOps are the principles and the tangible benefits it can help you realize. It is not another team or a single person. It is a common culture shared amongst a team that promotes ownership, accountability, increased collaboration, faster iteration and tearing down barriers that impede either of these.

Are you hungry to learn even more about Amazon Web Services?

If you are looking to begin your AWS journey but feel lost on where to start, consider checking out my course. We focus on hosting, securing, and deploying static websites on AWS. Allowing us to learn over 6 different AWS services as we are using them. After you have mastered the basics there we can then dive into two bonus chapters to cover more advanced topics like Infrastructure as Code and Continuous Deployment.

Top comments (10)

Collapse
 
anortef profile image
Adrián Norte

I think that what you say is what DevOps was intended to be, but to be honest, most developers I met have zero interest in the Ops part and they don't care. So, it kinda morphed into a position for individuals with skills at Ops and Dev trying to get some value from the original idea.

Collapse
 
david_j_eddy profile image
David J Eddy

"...most developers I met have zero interest in the Ops part and they don't care..."

This is a tough one. Some do, some don't, some move from Dev To Ops, some Ops move into Dev. IMO, everyone in an organization should care about the product/service the organization exists for. A dev who does not care about the output of their labor is, honestly, not someone I would want to work with. The laissez-faire attitude spreads and the next thing you know no one cares and people start leaving.

Collapse
 
kylegalbraith profile image
Kyle Galbraith • Edited

This has been my experience as well. It is true that not all developers want to do operations things and it's even more true in the vice versa. However, I believe that is a trend that is going to change and must change if folks want a face paced, quick iterations, and effective CI/CD environment.

Collapse
 
anortef profile image
Adrián Norte

I'm with you in the idea that you should care about the complete lifecycle of what you do. The problem is that reality is what it is and in more or less 10 years I have found 3 kinds of attitudes towards Ops from developers:

  • They don't care as long as the build is green. (most of them)

  • They have zero interest in Ops but they don't want to depend on other teams and so they learn DevOps to have freedom. (usually, highly skilled developers that pursue feedback as quickly as possible)

  • They care about Ops and eagerly learn about it. (I have met about 3 or 4)

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

I kinda get the feeling that DevOps is similar to the organisational transformation or culture that a lot of business management talks about.

Just that we focus on a different term to talk about it in the tech context, we focus on it exclusively to ship software.

This is reinforced further while I was reading some chapters of the DevOps Handbook.

Collapse
 
kylegalbraith profile image
Kyle Galbraith

Absolutely agree. The DevOps culture is largely a business transformation but taken from the point of view of developers. DevOps Handbook is a fantastic book to read on this topic.

Collapse
 
david_j_eddy profile image
David J Eddy

"...To me, this is missing the entire point of DevOps..." You and me both. I was recently at a client site and over heard a manager use the phrase "...if we are implementing agile devops we need X product...". It made me sad.

Collapse
 
kylegalbraith profile image
Kyle Galbraith

Exactly. I did a bit of consulting and this was a very common answer. I have seen how this plays out with Agile and I see folks taking the same approach when it comes to DevOps.

Collapse
 
hemanthyamjala profile image
Hemanth Yamjala

Hey Kyle, I can completely resonate with what you're saying. I think the issue is that while people rush towards developing their skills with new trends, they often neglect to develop their mindset to align with them. In order to build that DevOps culture, it's necessary for organizations to look beyond the technical skills of the development and operations professionals. Otherwise, as you said, there is no meaning as the point of DevOps is completely missed. I would like to know your views on this blog here that explains what it takes for organizations to match their pace with DevOps. Check it out here - cigniti.com/blog/key-aspects-to-co...

Some comments may only be visible to logged-in visitors. Sign in to view all comments.