DevOps: Culture vs. Tooling

One of the last questions asked in a DevOps interview is usually "so, what does DevOps mean to you?" I think this is a smart question, because DevOps is wildly misunderstood by the greater IT community. Some may answer that it's Continuous Integration and Releases, another may say it's having everything in Git, and the last might say that it's having tests available. All of these technical solutions do represent a key aspect of DevOps which is the tool chain, but it is the least important. Primarily, it is the least important because underlying the implementation of these tools is a make-or-break attitude into implementing them. For example, I may have a build but it might break or deployments may be manual. I may also have everything in git but I might only commit once a year. Or, I may have tests but all of them pass even if errors are thrown. As you can see, just because a team has these things, don't mean they are truly living the DevOps way.

Improving Toxic Team Culture

If you think that your team's culture is toxic or work is limited for some reason, there are ways you can go about improving it. Fundamentally, DevOps is about empowering individuals to do the work they need to do. There are a few immediate things you can do to get started on this journey:

1. Change your KPIs from "tickets resolved" to "problems fixed": this will allow your team to distinguish between the "busy work" of resolving repeated failures, and the real work of actually fixing the problem.
2. Begin code reviews: code reviews are important, not only because they may prevent bugs slipping into your code, but they also ensure that multiple members of your team understand and can work on your codebase. If code isn't reviewed, there is probably only a single person who understands it. The more of this code that is added your codebase, the further you embed single points of failure into your business. If a team member leaves and their code breaks for some reason, it may take days or weeks to resolve a problem that will inevitably come along.
3. Introduce a CI pipeline: if your team does work on production servers, this is an indication that the your work environment is in a precarious position. Introducing a CI pipeline will force your team to standardise their deployment processes and make sure rigour is applied to deployments. This should also reduce rework as failed production deployments should be a thing of the past.
4. Introduce automated testing: If you have a CI pipeline, good work. Now that you've got processes in place to reduce production impairing incidents, let's get started on introducing testing into the CI pipeline. Automated tests are great bang-for-buck as they only need to be defined once and are an immediate indicator if buggy code has been committed onto a branch.

These are just a few suggestions, but they at least give you an idea of simple things you can do to start to introduce your team to DevOps culture. The one thing that is important, is that if you decide to actually implement one of these things, you need to make sure you follow through. A half-implemented practice is worse than nothing because it allows you to operate with a false sense of security.

If you'd like to read more articles like this, please check out my blog engi.fyi.