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.