DevOps is a hot topic in the technology world. It's no longer just an isolated set of tools and processes which promise an automated future, it's an entire culture that's infiltrating every facet of software development.

This post will try to explain why the DevOps methodology itself is not boring. We will also try to explain why a feeling of boredom stems from properly implemented tools and processes. We also dive into how you can make DevOps more exciting while keeping your sanity intact.

Related Articles

What Does DevOps Mean?

The term DevOps, or "development operations," first appeared in the tech world in the early 2000s. It was a term used to describe a certain type of organization that was responsible for the entire application and software development lifecycle, from ideation to production.

Teams would be responsible for both the development and operations workflows, providing a more efficient way of working. As DevOps has grown in popularity, it has expanded beyond just operations teams.

Now, people are interested in speeding up their software development process using the term DevOps to describe the combined usage of infrastructure automation tools and best practices for team collaboration and communication.

There are two main components within DevOps that drive the culture. They are infrastructure as code and automated delivery. IaC is really just a way of organizing your code and infrastructure so that it is easily reproducible and shareable. Automated delivery is a method for automatically deploying applications and configurations without human intervention.

With the increase in automation, engineers may find themselves wondering when the next exciting change event may present itself. They may also wonder if they are automating themselves out of a job.

As a basis for understanding DevOps, you must understand that this practice exists to remove the excitement of a chaotic technology delivery process. DevOps is meant to be boring by nature.

As a side effect of DevOps being stable and consistent, organizations must look for other ways to keep their software engineers and DevOps engineers engaged through other means of excitement.

Why is DevOps Boring?

As companies begin implementing modern DevOps practices, some people may notice a lull in excitement. The tools, processes, and overall culture of DevOps may feel exciting at first but quickly turn into monotony. Why?

DevOps becomes boring because people approach it as a checklist. They focus on the tools and processes and completely ignore the culture and mindset that lies behind the methodology.

These people don't understand why they are implementing certain tools or why they are following specific processes. They are just doing it because they read an article that said their company should be adopting DevOps, or they read a book that talked about the "predictable flow of value".

What makes DevOps exciting is the culture behind it. The practices and tools are just the means of achieving a certain culture. If you try to implement DevOps but don't adopt the correct mindset and culture behind it, then you are going to end up with a boring and ineffective implementation.

Community Discussion

If you are looking for the communities view on why devops is boring, checkout this Reddit thread down below:

After a few years, DevOps gets super boring
byu/Zippyddqd incscareerquestions

Fewer Natural Learning and Growth Opportunities

A stable DevOps lifecycle will inherently bring a lower number of emerging technologies and opportunities to integrate emerging technologies. Sure, early on in DevOps adoption, the emerging tech will be all the rage, but that will subside as stability and consistency are driven into the pipeline.

Since continuous improvement is a fundamental principle of DevOps, teams should be encouraged to do some data-driven analysis looking for opportunities to become more efficient in their delivery cycles.

Pivots can also be made within the team. Someone who is primarily focused on ops should be put in a position to both share what they are doing and also be presented with opportunities to look at other fields like coding or security. This is true for all specialties that make up a function DevOps team.

Comfort in Previous Success

All too often, I see companies in the industry falling back on the comfort of their successes as an excuse to not rapidly evolve. DevOps should be putting companies in a position where pivots are much easier to pull off. Secondarily keeping a DNA of being lean and nimble should be a focus of any company.

Any company sitting back on its heels thinking it can keep doing what they are doing forever is going to be consumed by its competitors operating at a different level. Break that cycle by listening to the opportunities being presented by your DevOps Engineers and your Software Engineers to keep DevOps from becoming boring and your company from stagnating.

Never Being Complete or Finished

When completing a project, a person can get a huge dopamine rush along with a personal sense of accomplishment. DevOps doesn't really offer that in large quantities. Work is much more methodical, incremental, and bite-sized meaning a team's ability to celebrate a big win is less frequent.

If you want to truly adopt a culture of continuous improvement, you need to make sure that your team is constantly learning and improving their knowledge. This means your team should be continually looking for new books, podcasts, and ways that they can expand their skill set, improve their knowledge, and learn new things.

When DevOps is paired with Agile, those opportunities are even more spread apart. Everyone on the team is incrementally feeding their work into a larger integrated system. Resources may be assigned to a larger initiative for only a short period of time before being rolled off to another set of work.

DevOps Engineers are a Figment of your Imagination

A DevOps Engineer does not exist. They are not real. Yetis are more real than DevOps Engineers are.

DevOps is a methodology and a culture that does not require a role engineer it. There are many engineering practices that compose a full team practicing DevOps. Confusion about what someone is really intended to be working on will leave those individuals to fend for themselves and miss out on a healthy team dynamic.

When culture is suffering in a team practicing DevOps it can become boring or worse extremely frustrating. There is not a shared vision or goal that team is trying to achieve. This means that the work being performed is being done in isolation and under-appreciated. Let's face it, we are not doing our jobs for our own health, we do them to contribute to something bigger than ourselves.

▶ Key Insight

So, I know I just said that DevOps Engineers don't exist, BUT...

The role exists, but I believe is utilized incorrectly. DevOps Engineers are more often than not look at as Full Stack Engineer which are absolutely not real.

A team which is delivering against the DevOps methodology is a team full of DevOps Engineers. They all have specialties such as Software Development, Delivery Automation, Infrastructure, Quality Assurance, Data Platforms, etc. All of these skills are required to successfully deliver against the DevOps Methodology and it would be foolish to think a single individual is capable of being a master of every skill.

Building a composed team of engineers and architects which is functionally capable of delivering technology rapidly with a high degree or accuracy and risk mitigation is a challenging prospect, but yields high results when that is the focus rather than individual features being a focus.

The Hype Train

I see a lot of posts on Reddit which have individuals from different disciplines looking to make the jump from their current career path over to DevOps. Most of what I read leads me to believe that they are being sold a bill of goods which just isn't reality.

While I do believe that problem-solving in a space fully embracing DevOps is more complex than in any more traditional space, I do not believe that most companies are embracing DevOps fully. This means that job applicants are applying for and landing DevOps positions that are not actually meeting the spirit of DevOps. Organizations are generally looking for a little bit of help automating some manual processes but stop short of full adoption.

This will lead engineers to be as bored at this new shiny DevOps role as they were in their former system administration role.

Running out of People to Blame

Office politics can be entertaining to some. In a fully and healthily functioning DevOps culture, everything is treated as code, tested in code, operations happen in code, and releases are automated all of which remove a lot of formal human interaction in the daily development and release cycle.

Game of Thrones was not popular because Joffrey methodically picked apart Rob Stark and his armies. GoT was popular because of the drama, suspense, twists, and turns. Now, the office should not be a Game of Thrones style drama, but; DevOps is very good at transitioning from a culture full of interpersonal conflict into a blameless culture focused purely on technology which can be boring.

▶ Key Insight

Pride often gets in the way of rational decision making. Setting pride aside and working with your teams on moving specific needles forward which are good for the business and good for customers is the foundation needed for future success.

In a blame filled culture, everyone is paralyzed from performing their job because they will be blamed for their mistakes.

In a blameless culture, everyone is free to make progress towards anything which helps the business move its needles.

What Are Some Examples of Engineers Boredom Executing DevOps?

Below are some examples of different roles and how they can become bored with their job when DevOps is being practically utilized for its processes but not viewed as a persistent growth opportunity.

Debbie Developer has a Case of the Mondays

Debbie became a software engineer because of her love for puzzles. Solving complex scenarios and producing elegant maintainable code is her passion.

Early on in the DevOps adoption process, she was jazzed that there was a whole host of new problems to solve when transforming a traditional set of build jobs into something that could support CI/CD.

As time has progressed, she is feeling less fulfilled in her day-to-day job. The kinds of work she is performing have become far less complex and much smaller. There is almost no coordination between members of her team since she can just push code at will and let automation take over to push it into production.

It is the same daily slog over and over and over again.

Simon the Systems Administrator is Running Out of Work To Do

Servers create themselves. Simon doesn't need to log into the AWS console anymore to check anything because the platform is completely self-service.

When adopting DevOps, systems administrators will often find themselves developing a lot of code around system configurations. This works well because in their specific domain, they want consistency and operational efficiency.

Over time, Simon's work has been extremely helpful in level-setting expectations around solid delivery patterns. But what is next for Simon? There does not appear to be any new or related systems on the horizon for Simon to continue to grow his skills. Growth has stagnated and there really isn't a path forward for Simon to earn a senior systems administrator position.

Quintin Feels Like Their Role as a Quality Assurance Engineer is Monotonous

Developers are writing their own unit, functional, and integration acceptance tests. Quintin is left building some visual testing to be added to the delivery pipeline.

Quality assurance engineers are the glue that holds a development community together. They are well-versed in requirements and testing and they are constantly working with their developer counterparts to ensure their work will be accepted by customers.

DevOps can take away this sense of community in the development process. Individuals are responsible for contributing their own tests while they write code. As tests are passed, the code moves its way into production.

DevOps has effectively worked Quintin out of a job.

Connie the Cloud Engineer is Struggling to Provide Value

DevOps pipelines will consist of application code, test automation, system automation, and infrastructure automation (cloud or on-prem). Once developed, engineers will shift focus to day 2 operations. Once day 2 operations are tackled, what's left?

Connie felt value and excitement in the early days of DevOps, but is now isolated away from the rest of the team because systems have been stabilized, security is second nature, and AWS is effectively running itself.

5 Tips to Make DevOps Exciting Again!

We've covered why DevOps can become tedious, but what can you do about it? If you want to make DevOps exciting again, then you have to understand why it is exciting in the first place!

The reason DevOps is exciting for most companies is because of the focus on drastically improving your software development process. It's a way of improving communication, collaboration, and the overall quality of your software. It's a way of adopting a culture of automation.

Automation is important in DevOps because it directly impacts the speed of your software release cycles. It can also help improve the overall quality of your software as well as your organization.

Automation is a core component of DevOps. When you make automation a core part of your development process, you are able to reduce the number of repetitive tasks your organization has to perform. This means you can put less focus on manual tasks, and more focus on things that actually improve your software and the company as a whole.

Provide Growth Opportunities

Some companies confuse growth with "opportunities to become a manager". Most of the really good engineers and architects that I have met will "manage" a project because they want to see it succeed not because they want to be a manager.

Providing opportunities for growth in knowledge, automation, systems, development, operations, platforms, consulting, or any other area that your services or products may not be fully taking advantage of today.

As an example, if you have an awesome set of pipelines that obfuscate some of the complexities of doing automated delivery, challenge your team to package that up and white-label it. Have them use those packages to consult with other teams in your organization to level their automation skills up.

Inject Failures

We are always focused on delivering key projects, functionality, or needs of the business. With a narrow view of the world being delivered first, that does not leave a lot of room to poke at the softer edges of your products.

Introduce automated failure models like a chaos monkey. Start with planned times and have your chaos monkey start to take down some low criticality services and review the characteristics of what that means. There may be impacts in areas that you were not expecting.

This provides an opportunity to add some advanced troubleshooting to an area that the DevOps methodology took away through its inherent consistency and stability.

Incorporate User Feedback Into DevOps Processes

User feedback is important to any business because it allows you to understand your customers and discover ways to improve your product. However, user feedback is hard to come by because customers don't usually interact with businesses on a consistent basis.

In order to incorporate user feedback into your software development lifecycle, you need to be able to get consistent feedback from customers. There are two main ways to do this:

  • Use survey tools to let customers provide feedback on your product, team, and company.
  • Let customers interact with your team using live chat tools.

Both of these tools are easy to implement and can help you get useful and consistent feedback from customers. Feedback is also a great way to breathe some excitement into an otherwise stagnant work environment.

Be Realistic with Expectations

As I stated above, DevOps Engineers are not real. Business leaders need to come to grips with this fact and be very realistic with expectations around roles and work assignments. If you are looking to shortcut full DevOps adoption by hiring some DevOps engineers as a gap fill, you will not be able to provide an exciting environment that keeps your technology groups engaged.

Celebrate Completion

Get your teams together to do some good old-fashioned team building. Wins are wins no matter how big or small they are. Recognize your team's accomplishments because they deserve to be recognized.

The methodical pace of DevOps and Agile do not lend themselves to recognizing big wins or the sheer volume of work that it really takes to get to those wins. Team leads should focus on bringing their teams back to the center by recapping how much success they have had knowing their work is never done.

Conclusion

DevOps is not boring. It is an exciting change in the way that organizations approach software development. However, it is only exciting if you fully commit to the culture of DevOps and all the benefits it has to offer.

If you just implement the tools and processes without the culture and mindset, then you are only doing half the work and missing out on the benefits of the fully implemented DevOps culture.

If you want to make DevOps exciting again, you must ensure that you are fully committed to the culture. Only then will you be able to make the most of everything that DevOps has to offer.