DevOps Principles: 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 (long) this journey.

Change your KPIs

You would not believe the effect that changing team KPIs from "tickets resolved" to "problems fixed" has on individuals. It will allow your team to distinguish between the "busy work" of resolving repeated failures, and the real work of actually fixing the problem. DevOps is based on Lean practices, and a big part of that is measuring outcomes.

You need to make sure that your measurements are meaningful: Enron had some great measurements right before it collapsed. Pretty statistics mean nothing if they're not founded on a strong analytical foundation. You don't want to have your team working on things that result in no discernible output (either product or customer satisfaction). Deliver things that matter.

Review your Code

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. Spending a little time now will save frustration and (much more) time in the future.

Implement Continuous Integration

If your team does work on production servers, this is an indication that 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. By doing this, you're not-so-subtly changing the culture of the team to remove bugs and defects from their work. It will also mean that they deliver quality code once, rather than horrible code twenty times. Hopefully, failed production deployments should be a thing of the past.

Build Automated Tests

Now that you definitely 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. It also means that your team requires less time to manually test and gives them more confidence to push releases.

What Next?

DevOps is all about empowering your team to be better, do better, and deliver better products. You're not just making money; you're making experiences for your customers and your team. If every deployment results in negative experiences, you will end up losing on all fronts. You need to change your team culture, and not just give your developers production access to an AWS instance and a Jenkins instance. A team with good culture can become better at using tools - a team with bad culture will turn good tools into dumpster fires.

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.

Thanks for reading and if you'd like to continue the conversation, feel free to send me a DM or Tweet me @stophammotime.

Previously published at https://engi.fyi/devops-culture-vs-tooling/