6

I have worked in a number of software companies, and all of which have their own idiosyncrasies, which is perfectly understandable. The problem is, that some of these are (objectively) not good practices or counterproductive, or just plain odd and time-wasting.

When challenging some of these issues, an extremely common response is "this is how we always do it" or "that's how we do things here" as though that is justification in itself for the preservation of said practice. And despite offering decent counter-arguments, these phrases often seem to stop the conversation dead, and no further discussion takes place.

What would be a productive way to push for more productive reasoning for maintaining these practices and to not rock the boat, especially when fairly new to a company?

EDIT: It's not really so much about wanting people to adopt my ideas, but how to continue productive discussion when these phrases are dropped, as it happens so commonly and often acts as a full stop to discussion.

2
10

This isn't as crazy a reason as it may seem at first blush.

"We've always done it this way" means:

  • Everyone is familiar with it
  • Everyone knows how to do it
  • Everyone has a common frame of reference
  • Everyone is comfortable with it

Those are no small things to overcome.

In order to get people to embrace change your new solutions need to address those concerns, as well as demonstrate why your new way is better.

Now, let's step into thier shoes for a minute, and see how you look to them:

Hey! Lets change everything to something you don't know how to do, don't know how to use, aren't familiar with, and won't be able to share effectively with your team!

Of course you are not literally saying that, but that is how it is being heard.

To overcome the objections, you need to do some research

FIND OUT

  • What the reason for doing it X was to begin with
  • Does that reason still apply
  • What is the learning curve of the new way
  • How much of an improvement will it be
  • How much of a disruption will it be
  • What are the costs associated with the new way

Then, you need to put on your sales hat and address all objections, demonstrate all the strengths, and be ready to do a significant amount of hand holding.

You need to sell it hard, and get backup from people in power, or you are not going to get any buy in.

I designed a new system that has increased revenue by millions, but experienced heavy push-back initially.

It doesn't matter how good of an idea you have unless you can demonstrate it is a good idea.

Use the techniques above, and research a few of your own.

7
  • 2
    As a side point to what "this is how we always do it" could also mean job security and automating or changing it might expose them and cost them their job. In some cases, you wouldn't believe how much people depend on Excel or Access and spend days doing simple tasks that could be automated. – Dan Nov 1 '19 at 13:28
  • @Dan but those issues cannot be addressed within the purview of the question – Old_Lamplighter Nov 1 '19 at 14:32
  • 1
    An excellent answer and was very much what I was looking for. – azurez27 Nov 1 '19 at 16:42
  • A huge caveat on the first bullet list. Often "everyone" boils down to just one person: the one who cries “this is how we always do it”. The rest are afraid to oppose or simply don't care. – Stelios Adamantidis Nov 29 '19 at 18:35
  • @SteliosAdamantidis No, not at all. I'm currently updating an entire department, everyone means everyone. Especially when you're doing something like replacing their procedures with SAP. I had the same experience when I was first hired and replaced a disorganized procedure with my solution, and ditto that 20 years ago switching from a litereal Cut and paste, with real scissors, to a pagination system. But, I'm interned in your counter examples. Mine were at a major NY newspaper, and for a very large shipping company. – Old_Lamplighter Nov 30 '19 at 1:55
6

I like to iterate through a few thought exercises as a default response to this. You can scale the duration or intensity of each of these steps as appropriate.

  • Establish some degree of foundational goals. If you have some sort of company goals, or a vision statement, or something like that - you can effectively skip this step.
  • Determine the appropriateness of the current process and/or the potentially improved process against those goals
  • Use the relationships between processes and goals as your justification for making a change, if appropriate.

All too often, people on both sides of this argument get lost trying to justify things because they can't make an explicit connection to some basic, agreed-upon goal. This is an easy trap for software developers to fall in to - in the interest of "improving" code, or "making things better," you can easily get in a position where you are chasing efficiencies that - although potentially valid - don't really matter according to the direction the company wants to move in. Having an overall strategy, or goals, or other driving force establishing a direction and priority is important because it removes the subjectivity.

So - if you're the one trying to identify a change - make sure you can justify it. And, if people do throw up the "but this is the way we've already done it" excuse, you can prompt them to try to justify the current process by tying it back to the goals. Go in with an open mind, as either side may actually be correct.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .