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?

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