How Do You Overcome “We Have Always Done It This Way”?
I work in computers and my son works in manufacturing, but both of us loathe a single phrase:
We have always done it this way.
Please allow me to be clear on this. If you can back up this statement with “Because…”, and you list out valid points, even if I disagree with them, we’re all good. However, frequently, if you follow up this statement with the simplest of questions, “Why?”, you don’t get good answers. Usually, you’ll get a repetition of the phrase.
This statement is especially painful when we start talking about attempting to change the way we develop and deploy software, possibly through the adoption of some sort of DevOps-style approach. I have personally seen consulting projects I worked on fail because we hit this very specific wall. I do believe that this statement may be the biggest hurdle to getting a change to automation implemented. So, the question comes up pretty frequently: How do you overcome it?
I wish I had a strong, always successful, answer to that question. Instead, I have a few suggestions that might help, but there are no guarantees. Let’s talk through some possible solutions.
Ask Why
Don’t let the statement stand. Get a justification. Ask the question, why.
Now, I’m not guaranteeing that this will solve the problem. However, you get one of two opportunities out of asking this question. The first opportunity is that you get an explanation as to why a particular method or practice has been adopted. There may be perfectly valid reasons. Heck, you may agree with those reasons and decided to incorporate them into your suggestions for automating their deployments. Conversely, you may find that the reason they were doing some particular thing was because of a technical limitation that no longer exists or won’t be applicable if you change the way things are done. You may even find that the reason is just pure malarkey and by getting them to explain it, you get them explain to you why things need to change.
The next opportunity that you could get by asking for an explanation is the simplest of answers: I don’t know. This is the best answer to get if you’re hoping to change people’s attitudes and approaches. If no one can justify why they’re doing work, other than because they’ve been told to, the chances of changing that particular bit of work are quite high. After all, most of us are lazy at heart (or maybe that’s just me). If I can eliminate some work, especially work I’m doing for no reason at all, I can spend time doing stuff that is more useful.
However, these are just the opportunities presented by the question. Sometimes, even if they don’t know why they’re doing a thing a particular way, they’re going to insist on continuing. Now what?
Measure the Pain
Just because you’ve always done something doesn’t mean it’s flawless and efficient. If your existing processes were working well, no one would even be having the discussion where the phrase “We have always…” comes up. So, go about finding those pain points that indicate how poorly the existing process is working.
Focus first on any actual outages caused by the process. When focusing on the outage, emphasize the pain to the business, not the pain to the IT department. If possible, demonstrate lost income or lost opportunities. Show how these outages are preventable by changes to the process.
Next, focus on the time involved in the deployment. Can you prepare for a deployment in a short period or does it take days of prep work? Show how this is negatively affecting ITs ability to deliver functionality. Also show how long the deployment itself takes. Include any additional rework necessary after the deployment. Finally, as above, show how the time involved in the existing process negatively affects the business.
Finally, measure how often a deployment fails. Did you have to do it more than once? Did you spend the weekend recovering from the deployment? Was there weeks of follow up to ensure that everything was working?
Gather all this into a document that you can share with your peers and with management. Often, everyone just sees these failing/failed deployments as a cost of doing work. Emphasizing the pain involved can help to suggest ways to change. However, people can be extremely resistant to any change. This is where you have to try to help them along.
Be Supportive
If you can get actual reasons why a given process was adopted, don’t attack the process. Instead, acknowledge the common sense approach that was taken at the time. Let them know, that, yeah, given the same knowledge and experience, that was the right call. However, times have changed. What was a good call 3, 5, 15 years ago, isn’t any more.
This method is all about education. It’s not an attack on previous choices. Even if those choices were bad, and sometimes they are very bad indeed, you need to approach this with the attitude of lifting everyone up. Tearing down the existing process, however poor, is going to hurt the people who built that process. So even in cases where the real need is to almost literally set fire to the existing process, don’t take that approach. Focus on teaching them why that process choice hurts and how we can improve things by changing it.
One methodology that seems to work quite well for this kind of education is to build a community of practice. This is basically creating a training team within your organization who will figure out the best approaches to resolve these types of issues. They can then communicate with the rest of the teams in the organization. We know from the State of Database DevOps survey results that a community of practice is extremely common method within companies, especially larger organizations.
Conclusion
I want to be completely open and clear on this, these don’t always work. I’ve gone through consulting gigs where I gathered data on existing processes, at the request of the organization I have to emphasize, and identified problematic approaches. I showed ways they could improve and was summarily shot down because “we’ve always done it this way.” Sometimes, the best you can do is plant the seed that there is a better way. It might take a while, but people will come around. I know of one organization that dug up a white paper I’d written for them five years previous and started to implement it. Yes, they needed to change. However, they weren’t ready. Following these methods, you may be able to change the organization’s approach. Alternatively, you may be able to prepare them for a change they’ll make when they are better situated.
Good luck!
For some additional input on this, check out the Thursday Ask The Experts section of the Redgate Summit.
Also, for some additional reading, please look at the following:
Ten Steps to Building a Collaborative DevOps Culture
Read next
Blog post
Challenges to Implementing Database DevOps: How Do You Get The Data Team On Board?
I think this is my single favorite question that came up at the recent panel discussion: How do you get DB folks who just go in and make changes to understand they need DevOps, source control, change management, etc.? There’s a lot to answer in this question, however, to keep this down to a blog
Product learning article
A DBA's Journey towards Database DevOps
John Morehouse describes how a quest to help solve his organization's "deployment bottleneck" led them to a place where they could both deliver application and database changes into the wild at a pace to satisfy customer demand, and achieve a better work-life balance for the team, both of which are well worth having.
Increase the frequency and reliability of deployments with Database DevOps
Automate database deployments across teams and technologies
From version control to continuous delivery, Redgate Deploy lets your teams automate database development processes so you can accelerate software delivery and ensure quality code. Building on your continuous delivery process for applications, and incorporating Redgate’s industry-leading tools and Flyway migrations framework, Redgate Deploy extends DevOps to your databases. Request a demo
You may also like
Blog
What is Test Data Management (TDM)?
Blog