How to overcome skepticism in my team to improve our engineering landscape?

Question

Over the past year, we've focused on developing our product quickly, which has led to a significant amount of technical debt in our codebase. As a result, we've shipped applications without proper architecture and planning. However, when I suggest refactoring or re-architecting to my team, many of the senior developers and the engineering manager are skeptical. In my opinion, I am not just offering refactoring for just sake of refactoring; it's necessary because our current code base lacks abstraction and separation of concerns and has slow development times.

Examples:

Adding a new column to the database takes 1-2 days
Or changing some code breaks another part of the application(lack of separation of concerns and abstraction)
Another example, recently I introduced integration tests to our team because we manually tested a lot of stuff on staging before deployment, in that case, my EM's argument was integration tests are very slow to run on every build.

In those examples, how can I reduce skepticism in my team and bring more productivity, and more good code quality, and best practices to my team?

Rahul Pandey · Accepted Answer

Do you need permission to get started with your ideas? e.g. could you run the integration tests as non-blocking on every build? So it doesn't slow anyone down.  Then show how X number of bugs would have been caught earlier with the integration tests. Once you show the impact, it'll be much easier to get people onboard.  Here's a good Q&A from a while ago about this:

How to overcome skepticism in my team to improve our engineering landscape?

Discussion